user664833's questions

Em termos de capacidade e desempenho de pesquisa , quais são os prós e os contras de implementar tags como um campo de texto completo ou ou ?arraytext

Estou vendo limitações de capacidade na escolha de implementar tags com uma matriz, porque me parece que se uma matriz contém ['juicy fruit'], alguém que está procurando 'fruit'não encontrará esse registro (por exemplo, tags && ARRAY['fruit']não o encontrará). A pessoa que criou esse registro teria que inserir algo mais parecido ['juicy fruit', 'juicy', 'fruit']para que seu registro fosse encontrado com apenas uma pesquisa por 'fruit'ou 'juicy'. Considerando que, se eu implementar tags como text, uma pesquisa por 'fruit'localizará 'juicy fruit', e ainda mais, se eu implementar tags como texto completo , localizarei 'juicy fruit'ao pesquisar com a string 'fruits'(plural). Além disso, acho que não haverá perda de desempenho na pesquisa de texto completo. Pensamentos?

Mas talvez o objetivo das tags seja a correspondência exata .

Digamos que estou pesquisando em três colunas de texto. Eu não quero apenas resultados que correspondam a uma determinada palavra ou frase, mas também quero pesá-los ( column A > column B > column C) - ordenando assim os resultados de forma que as linhas que correspondem à palavra na coluna Aapareçam mais altas do que as correspondentes na coluna B, e aquelas correspondentes na coluna Baparecerão mais altos do que os correspondentes na coluna C.

Isso é possível? Você pode me fornecer alguma terminologia ou sugestões para leitura adicional?

Observe o exemplo a seguir, começando na linha superior ( id=9) e vá descendo, selecionando um limite de 4linhas com sec's que ainda não vimos. Nós "selecionamos" id=9porque ainda não temos sec=1. Continuamos a descer assim, mas quando chegamos id=7, pulamos porque já temos sec=5(da carreira com id=8). Continuamos da mesma maneira e finalmente paramos id=3porque acumulamos 4linhas (nosso limite desejado).

 id | sec
----+-----
  9 |   1  <- 1
  8 |   5  <- 2
  7 |   5  # skip, already have sec=5
  6 |   4  <- 3
  5 |   1  # skip, already have sec=1
  4 |   1  # skip, already have sec=1
  3 |   3  <- 4
  2 |   2
  1 |   1

Claro que o SQLalgoritmo pode (será!) ser diferente do que eu descrevi.

Resultado desejado:

 id
----
  9
  8
  6
  3
(4 rows)

Se eu quisesse aumentar o limite de 5linhas, a linha com id=2 seria incluída nos resultados. No entanto, se eu aumentasse o limite de 6linhas, a linha com nãoid=1 seria adicionada porque já foi vista.sec=1

Nota: Embora não deva importar, estou no PostgreSQL 9.3.1 .

Caso você queira construir rapidamente a tabela para testar isso:

CREATE TABLE my_table (id serial primary key, sec integer DEFAULT 0 NOT NULL);
INSERT INTO my_table (sec) VALUES
  (1)
, (2)
, (3)
, (1)
, (1)
, (4)
, (5)
, (5)
, (1);
CREATE INDEX index_my_table_on_sec ON my_table (sec);

Eu posso ver a corrente search_pathcom:

show search_path ;

E eu posso definir o search_pathpara a sessão atual com:

set search_path = "$user", public, postgis;

Além disso, posso definir permanentemente o search_pathpara um determinado banco de dados com:

alter database mydb set search_path = "$user", public, postgis ;

E posso definir permanentemente o search_pathpara uma determinada função (usuário) com:

alter role johnny set search_path = "$user", public, postgis ;

Mas eu gostaria de saber como determinar quais são as configurações do banco de dados e da funçãosearch_path (com relação a ) antes de alterá-las?