Tiago eu tbm fiz utilizando UNION e da maneira que mencionei no email anterior. Dei uma lida no FTS e acho que vai ficar inviável, pois terei que criar índices em todas as tabelas, e a busca será feita em vários campos. Então terei que criar índices compostos, etc. E este tipo de procura que pretendo fazer, vai ser pra qualquer tabela ou tela do meu sistema. Mas o lance é testar o melhor, ou seja, o mais rápido. Valeu por todas os opiniões.
-----Mensagem original----- De: [email protected] [mailto:[email protected]] Em nome de Marcelo Silva Enviada em: quarta-feira, 5 de setembro de 2012 13:46 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] Localizar em todos campos de uma tabela Pois é, as vezes temos que dar uns nós pra conseguir o que o chefe pede :) Esse site que passei o cara pode procurar pela frase que quiser e o sistema faz todos os cruzamentos trazendo os assuntos mais proximos de acordo com as palavras da frase. Nao vi como fazer isso numa procedure se muitos problemas -----Mensagem Original----- From: Tiago Adami Sent: Wednesday, September 05, 2012 1:33 PM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Localizar em todos campos de uma tabela Em 5 de setembro de 2012 12:25, Guimarães Faria Corcete DUTRA, Leandro <[email protected]> escreveu: > 2012/9/5 Marcelo Silva <[email protected]>: >> Pra isso tenho uma tabela de indices que guarda todas as palavras do >> cadastro, do campos que quiser... > > Parece desperdício… Depende de como foi implementado. Certa vez fiz testes com o FTS para algo semelhante à pesquisa do Google, mas foi desastroso ao passo que tornou-se lento demais (se não me engano na versão 8.3). Já fiz algo semelhante indexando todo o conteúdo de uma coluna texto em outra tabela. Como por exemplo, o conteúdo da coluna em um registro: "Tiago José Adami" criaria 3 registros na tabela de indexação [1]. Aí depende de criar uma consulta AND/OR dependendo de como for feita a consulta. Foi uma atitude desesperada, nos testes a velocidade de consulta foi bem satisfatória pois a coluna na tabela de índices, obviamente, era indexada. Mas a dor de cabeça veio com a complexidade de procedures e triggers por baixo do pano para gerir toda esta funcionalidade, o que deixava a alteração de registros muito lento. No final, como eram 4 colunas tipo VARCHAR indexadas, optei por fazer uma VIEW com 4 SELECTs em UNION. Não ficou perfeito, mas ficou mais rápido que o FTS. Não sei se hoje com a versão 9.1 o FTS está mais rápido, nunca mais o utilizei. [1] http://pastebin.com/NTNUDaWX -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
