No dia 5 de Setembro de 2012 14:41, Saulo Morais Lara < [email protected]> escreveu:
> 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 > Pessoal cuidado com o *top posting.* * * *Att. Glauco Torres*
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
