From: | BhEaN <listas(at)bhean(dot)com> |
---|---|
To: | pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Diferencia entre indices btree, rtree y hash |
Date: | 2009-05-22 11:34:39 |
Message-ID: | 4A168DCF.2070909@bhean.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Muchas gracias de nuevo a todos por vuestra ayuda...
Después de todo, parece que la mejor solución será actualizar a Postgres
8.3 y realizar las búsquedas con índices de tipo "full_text"...
Una vez hecho ésto, me aconsejan consultas sobre esos campos con MATCH
[] AGAINST [], o mejor con los LIKE de "toda la vida"? ;)
Un saludo,
Silvio Quadri escribió:
> El día 19 de mayo de 2009 7:08, BhEaN <listas(at)bhean(dot)com> escribió:
>
>> Antes de nada, muchísimas gracias a todos por vuestras respuestas....
>>
>> Os contesto debajo de cada parrafo:
>>
>>> rtree ya no existe. Fue reemplazado por GiST ("generalized search
>>> tree"), el cual es un sistema de indexamiento para tipos complicados --
>>> por ej. se usa para indexar tipos geométricos y también para los índices
>>> de búsqueda en texto, entre muchas otras cosas.
>>>
>>>
>> Eso es lo que necesito, un índice de búsqueda en texto...
>>
>>> El otro sistema de indexamiento extravagante es GIN; es un índice
>>> invertido. También se usa para búsqueda en texto (es más rápido en
>>> búsquedas que GiST, pero mucho más lento para agregar nuevos valores).
>>> Se puede usar para otras cosas también obviamente.
>>>
>>>
>> Eso suena mejor que GiST, puesto que la relación de inserciones/lecturas
>> será muy baja... se haran muchísimas más consultas que inserciones, por lo
>> que quizás me interese más éste tipo de indice...
>>
>>> Hash es un tipo de índice que en Postgres no es recomendable por el
>>> momento, así que no lo uses porque tiene varios problemas.
>>>
>>> Así que tu única alternativa es el btree. Dado que no puedes almacenar
>>> más de 2000 y pico caracteres, vas a tener que buscar mecanismos
>>> alternativos. Si quieres indexar campos grandes de texto, ¿quizás lo que
>>> necesitas en realidad es usar el sistema de búsqueda en texto? Te
>>> podemos dar consejos más específicos si nos dices exactamente de qué
>>> naturaleza son los datos y cómo serán las consultas.
>>>
>>>
>>>
>> Ok... siento no haber sido más explícito... lo que tengo exactamente es una
>> tabla con muchos anuncios clasificados (los típicos anuncios de "vendo
>> blablabla", o "compro blablablablabla"... hay varios millones de éstos
>> anuncios.... y lo que necesito es optimizar todo lo posible las búsquedas en
>> ella, ya que debo permitir búsquedas de palabras en el texto y título de
>> dichos anuncios... es decir, búsquedas del tipo LIKE '%blablabla%' (lo cual
>> tiene pinta de que va a ser horrible para la BBDD, pero es lo que hay,
>> jejejee...). No dispongo aún de los datos "reales", por lo que no puedo
>> hacer pruebas de rendimiento con un índice u otro, sino... simplemente
>> "probaría" a hacer búsquedas con un tipo de índice... luego con otro... y
>> así hasta dar con el más optimo, pero no los tengo aún, así que tengo que
>> preparar el tema un poco "a ciegas".
>>
>
>
> Like '%blablabla%' no va a usar un índice tradicional. Revisá la
> documentación acerca de "full text search"
> (http://www.postgresql.org/docs/8.3/static/textsearch.html) que te va
> a servir de ayuda.
> Saludos!
>
>
> Silvio
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Silvio Quadri | 2009-05-22 12:06:05 | Re: Capturando la salida de ANALYZE |
Previous Message | Eduardo Morras | 2009-05-22 06:25:06 | Re: Capturando la salida de ANALYZE |