RE: [pgsql-es-ayuda] Búsqueda indexada desubstrings

Hola:
por lo que estuve viendo, va a haber que ir ajustando el límite de la
similaridad, según los datos que tngas cargados. Para ajustar la
similaridad: select set_limit(.2); -- el default es 0.3. Este valor es por
sesión, así que es posible que dependiendo de la tabla y columna quieras
indexar, tengas que ir ajustando desde tu aplicación el valor.

Respecto el texto 'gaviota', 'juan salvador gaviota' tiene menos similaridad
que el texto 'gaviota'.
Va a depender de tus textos encontrar un valor que te permita filtrar sin
traer 'aireo' o 'tire'.

Todavía no lo use extensivamente ni lo probé con una tabla que realmente me
sacuda el motor...

Saludos.

-----Mensaje original-----
De: pgsql-es-ayuda-owner(at)postgresql(dot)org
[mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org]En nombre de Luciano Burotti
Enviado el: martes, 09 de agosto de 2005 16:18
Para: Alvaro Herrera
CC: dario_d_s(at)unitech(dot)com(dot)ar; Guillermo Schulman; lista de correo de
postgres
Asunto: Re: [pgsql-es-ayuda] Búsqueda indexada desubstrings

Hola a todos, yo tengo el mismo problema que Guillermo, es decir que
necesito reemplazar el LIKE por algo mas eficiente pero que se comporte
de la misma manera.

Probe como dice Dario pero el tema es que cuando la cadena de busqueda
es relativamente corta y el valor del campo es lo suficientemente largo
el coeficiente de "similitud" es muy bajo y en esos casos el % no me
retorna los registros que yo quiero (como lo haria el LIKE).

Ej: select * from ciudad where nombre % 'aire' and nombre ilike
'%aire%';

En la tabla ciudad existe el registro 'Ciudad Autonoma de Buenos Aires'
y cuando lo compara con 'aire' retorna un coeficiente muy bajo.

Como se podria salvar este problema?

Gracias
Luciano

On Fri, 2005-08-05 at 18:48, Alvaro Herrera wrote:
> On Fri, Aug 05, 2005 at 05:35:36PM -0400, dario_d_s(at)unitech(dot)com(dot)ar wrote:
> > okey, perdì el mail q estaba redactando, asi q resumo.
> >
> > Esa cadena es muy corta. Amsterdam, amsa... depende de tu juego de
datos.
> >
> > select * from tabla where campo % 'ams' and campo ilike '%ams%'
>
> Duh, era tan obvio y no se me ocurrio :-P
>
> > correrlo con un explain adelante para asegurarte que primero usa el
> > índice y después filtra por el ilike.
> >
> > con el % forzas el uso de índice, y esa cadena es muy corta, es
> > probable que no sea muy selectiva (i registros + i reg * seeks en el
> > índice) y que tengas peor performance que con un ilike pelado (j
> > registros, no mucho más grande que i). Depende de tu hardware y los
> > costos configurados en el planeador de consultas)
>
> Es cierto que la cadena es corta, pero dado el indice por trigramas no
> deberia tener problemas. Sobre todo si la tabla con texto a buscar es
> suficientemente grande, cosa que probablemente se cumple, porque de lo
> contrario el recorrido secuencial seria muy rapido.
>
> Lo malo de usar el ilike pelado, es que es imposible usar ninguna clase
> de indice. Cuando la tabla es muy grande, no es una aproximacion
> factible de usar.
>
> --
> Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
> "La experiencia nos dice que el hombre peló millones de veces las patatas,
> pero era forzoso admitir la posibilidad de que en un caso entre millones,
> las patatas pelarían al hombre" (Ijon Tichy)
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
>
> http://archives.postgresql.org/pgsql-es-ayuda
>

---------------------------(fin del mensaje)---------------------------
TIP 3: si publicas/lees desde Usenet, por favor envía "subscribe-nomail"
a majordomo(at)postgresql(dot)org para que tus mensajes puedan llegar
a los suscriptores de la lista