Re: FTS

Hola Guillermo

On 11/08/16 08:54, Guillermo E. Villanueva wrote:
> Anthony muchas gracias por tus explicaciones. Es como dices, la
> palabra "salta" está en el 99% de los registros, en este caso se
> refiere a la provincia llamada Salta y no al verbo saltar. ¿No hay
> manera de forzar a que el lexema de Salta sea "Salta"? como cuando
> buscamos en google con comillas.
Tal vez puede que te ayude con esto definir tu propio diccionario
personalizado (nunca lo he tenido que hacer, pero una vez vi que se
puede hacer :D).
O tal vez probar con el truco de diccionarios distintos en las búsquedas
e indices para forzar a que un lexema sea distinto del idioma nativo y
permita indexar más palabras, esto creo que provoca que el indice sea
más grande (no se cuando bueno o efectivo puede ser eso en tu caso, pues
incluso las stop words son distintas)

por ejemplo se obtienen lexemas distintos para idiomas distintos con la
misma frase,

select to_tsvector('english','Salta es una provincia');
"'es':2 'provincia':4 'salta':1 'una':3"

select to_tsvector('spanish','Salta es una provincia')
"'provinci':4 'salt':1"

saludos
> Creo que una alternativa sería agregarle otra condición con LIKE pero
> ya no usaría índice ni las virtudes de FTS.
> Muchas gracias de nuevo.
>
> Guillermo
>
> El 10 de agosto de 2016, 17:52, Anthony Sotolongo
> <asotolongo(at)gmail(dot)com <mailto:asotolongo(at)gmail(dot)com>> escribió:
>
> 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
>
>