junior Prado escreveu:
> Galera,
>
> Na site do postgres http://www.postgresql.org.br/Documentação
> encontrei um material sobre indice
> * Tutorial de Tsearch - Indexando textos no PostgreSQL - Baixar o PDF
>
> No inicio do texto
> "As vezes é necessário criar aplicações que buscam dados de acordo com
> palavras contidas em textos extensos. No entanto a procura de padrões
> em grandes cadeias de caracteres é extremamente custosa em termos
> computacionais. Uma das soluções para esse problema comum é quebrar os
> textos em átomos maiores que um caractere, ou seja, utilizar
> palavras-chave para indexar. O uso de palavras-chave reduz
> consideravelmente o número de elementos distintos a serem indexados,
> além de possibilitar algoritmos muito mais eficientes para a busca.
> Torna-se possível utilizar uma estrutura de dados que organize todas
> as palavras contidas em um texto em um formato que possa ser
> facilmente percorrido: uma árvore. Outra vantagem na utilização de
> palavras-chave é que elas possuem, diferentemente de meras cadeias de
> caracteres, um significado. Isso pode ser utilizado para criar
> ordenamentos baseados em relevâncias de palavras em um determinado
> contexto. Um ótimo exemplo disso são os sites de busca na web, que
> procuram por palavras-chave presentes em imensas bases de dados
> contendo documentos."
>
> Concluindo, os índices com tipos numéricos são mais rápidos...
> Alguém nega minha afirmação?Me dê uma prova?
Não misture as coisas, uma coisa é a pesquisa verificando se um campo é
igual a um valor dado. Outra coisa completamente diferente é a
utilização do módulo tsearch que serve para saber se uma ou várias
palavras *estão contidas* em um texto. Esta última sim, é muito custosa.
Prova:
teste=# create table teste(codint integer, codstr varchar(10));
CREATE TABLE
teste=# create index teste_idx1 on teste(codint);
CREATE INDEX
teste=# create index teste_idx2 on teste(codstr);
CREATE INDEX
teste=# \d teste
Tabela "public.teste"
Coluna | Tipo | Modificadores
--------+-----------------------+---------------
codint | integer |
codstr | character varying(10) |
Índices:
"teste_idx1" btree (codint)
"teste_idx2" btree (codstr)
Preenchi o banco com 1,5 milhões de registros com valores totalmente
diferentes e vejamos os resultados
teste=# explain select * from teste where codint = 1;
QUERY PLAN
------------------------------------------------------------------------
Index Scan using teste_idx1 on teste (cost=0.00..8.27 rows=1 width=8)
Index Cond: (codint = 1)
(2 registros)
teste=# explain select * from teste where codstr = '1';
QUERY PLAN
------------------------------------------------------------------------
Index Scan using teste_idx2 on teste (cost=0.00..8.27 rows=1 width=8)
Index Cond: ((codstr)::text = '1'::text)
(2 registros)
teste=#
Portanto, não confunda tsearch que trata de full text index com índices
btree. No segundo tipo, em consulta a diferença é mínima, o problema é
na atualização que o índice de campos numéricos é mais rápido. Até
porque é mais fácil ordenar números do que cadeias de caracteres.
Abraço,
--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
