Hola Guillermo
On 10/08/16 12:32, Guillermo E. Villanueva wrote:
Buenas tardes , he leído sobre el tema Postgres y FTS en varios sitios
y lo he utilizado varias veces pero al decir verdad, sigo
entendiendolo muy poco.
Si alguno tiene tiempo y puede ayudarme, les comento mi inquietud.
Tengo la siguiente consulta:
SELECT *
FROM tescrito t
WHERE to_tsvector('spanish',escritodtxt) @@
to_tsquery('spanish','*salta*')
y tengo un índice creado
CREATE INDEX fts_escritodtxt ON public.tescrito
USING gin (to_tsvector('spanish'::regconfig, escritodtxt));
La tabla tiene 65300 registros
El planificado me dice que realizará un seq scan y de hecho, la
consulta demora mucho.
Si cambio la palabra a buscar, por ejemplo por 'casa'
SELECT *
FROM tescrito t
WHERE to_tsvector('spanish',escritodtxt) @@
to_tsquery('spanish','*casa*')
Entonces demora menos y el planificador ahora dice que si utilizará el
índice.
Preguntas:
En que se basa postgres para decidir si utiliza o no el índice si lo
único que cambié es la palabra a buscar?
Tengo entendido que se basa en las estadísticas para ver si usa el
indice o no, por ejemplo puede que el optimizador considere que es
mejor escanear la tabla completa antes de usar un indice, pues el
resultado está en un porciento grande de la tabla ( no se el porciento
exacto :( ), ejemplo:
De:
explain analyze
select * from customers where customerid >10000
Obtenemos:
"Index Scan using customers_pkey on customers (cost=0.29..538.29
rows=10000 width=268) (actual time=0.019..1.764 rows=10000 loops=1)"
" Index Cond: (customerid > 10000)"
"Planning time: 0.113 ms"
"Execution time: 2.064 ms"
Y de:
explain analyze
select * from customers where customerid >1000
Obtenemos:
"Seq Scan on customers (cost=0.00..738.00 rows=19000 width=268) (actual
time=0.273..3.120 rows=19000 loops=1)"
" Filter: (customerid > 1000)"
" Rows Removed by Filter: 1000"
"Planning time: 0.189 ms"
"Execution time: 3.640 ms"
Como ves con solo cambiar el valor del customerid el optimizador usa el
indice o no, y este optimizador de PostgreSQL ha resultado ser inteligente.
pero si consideras tu que no esta bien la decisión del optimizador
puedes "tomar el toro por los cuernos" y obligarlo a que use el indice
por ejemplo:
set enable_seqscan = off;
explain analyze
select * from customers where customerid >1000;
Obtenemos:
"Index Scan using customers_pkey on customers (cost=0.29..1019.79
rows=19000 width=268) (actual time=0.013..5.099 rows=19000 loops=1)"
" Index Cond: (customerid > 1000)"
"Planning time: 0.076 ms"
"Execution time: 5.820 ms"
vaya que se demora más con el indice que con el scan para el customerid
>1000
Será que el tsquery de 'salta' es una palabra que no se indexa?
el to_tsvector obtiene los siguientes lexemas(donde esta 'salta'):
SELECT to_tsvector('spanish','saltar un muro que es bien alto');
"'alto':7 'bien':6 'mur':3 'salt':1"
puede que 'salt' que es el lexema de 'salta' sea un porciento grande de
la tabla y por eso el decide no usar el indice (de todos modos puedes
forzarlo a usar el indice con set enable_seqscan = off; , vaya ser que
se equivoque el optimizador, prueba a ver si se equivoca el optimizador )
Para el caso de 'spanish' Aparte de crear el índice es necesario crear
o configurar algo mas?
hasta donde yo lo he usado no me ha sido necesario configurar más nada,
pero puede que haya que hacer algo más para lo que requieres
Desde ya les agradezco la ayuda que me puedan brindar.
Saludos
Guillermo
Saludos
