Re: FTS

Gracias por las sugerencias Anthony, pruebo esa alternativa y les comento.
Saludos!

El 11 de agosto de 2016, 11:51, Anthony Sotolongo <asotolongo(at)gmail(dot)com>
escribió:

> 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>
> 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
>>
>
>
>