Skip site navigation (1) Skip section navigation (2)

Re: B-Tree o HASH

From: Raúl Andrés Duque Murillo <ra_duque(at)yahoo(dot)com(dot)mx>
To: "Gerardo Herzig" <gherzig(at)fmed(dot)uba(dot)ar>,"Miguel Angel Hernandez Moreno" <miguel(dot)hdz(dot)mrn(at)gmail(dot)com>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: B-Tree o HASH
Date: 2010-02-24 19:36:52
Message-ID: 4FD84AB402BD4A75995914A646070EB6@devamadeus.net.co (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
>
> Usar HASH cuando el criterio de busqueda sea por igualdad.
>
> Usar B-tree con cualquier otro criterio de busqueda (>, >=, <=, LIKE, etc)
>

Si, estas en lo correcto, pero hacer la claridad que SOLO se usa un índice 
BTREE en un like si el inicio del criterio es fijo ej. 'criterio%' pero no 
si es '%criterio' esto es porque para navegar a través de un árbol binario 
debes tener un punto de entrada.

Otro punto a aclarar es que si usas un locale diferente a 'C' debes crear el 
índice con 'xxxxx_pattern_ops' para que lo utilice al consultar sobre 
cadenas.

Algo que leí alguna vez es que NO se recomienda utilizar índices HASH ya que 
el grupo de desarrollo de postgresql no los seguirá manteniendo ya que la 
ganancia de performance entre un hash y un btree es muy poco y no justifica 
su mantenimiento a futuro. Esto lo dice en la documentación de la versión 
8.1:

http://www.postgresql.org/docs/8.1/static/indexes-types.html

Pero miré la documentación de la 8.4 y la nota cambió:

http://www.postgresql.org/docs/8.4/static/indexes-types.html

Vuelven a nombrar la necesidad de hacer un REINDEX después de un crash pero 
ahora ya no hacen la comparación de performance entre los HASH y los BTREE 
... cambió esta apreción de la versión 8.1 a la 8.4?

Atentamente,

RAUL DUQUE
Bogotá, Colombia 


In response to

Responses

pgsql-es-ayuda by date

Next:From: Ing. Marcos Ortiz ValmasedaDate: 2010-02-24 19:40:12
Subject: Manual de Desarrollo de PostgreSQl actual
Previous:From: Miguel Angel Hernandez MorenoDate: 2010-02-24 18:27:36
Subject: Re: B-Tree o HASH

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group