From: | "Jaime Casanova" <jaime(at)2ndquadrant(dot)com> |
---|---|
To: | Pedro Ricardo <hades_inf(at)elhacker(dot)net> |
Cc: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: Sobre Performance de consultas |
Date: | 2011-07-17 20:32:55 |
Message-ID: | 87bows3ax4.fsf@casanova1.SEINGALT |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Pedro Ricardo <hades_inf(at)elhacker(dot)net> writes:
> TOPIC: Sobre Performance de consultas
>
> Hola a todos, bueno pues tengo muchas preguntas sobre el performance de los select, actualmente trabajo con tablas que tienen millones de registros, ahora
> es cuando siento que mis consultas estan pesimas ... lo que busco es mejorarlas, ahora bien... la unica forma de hacerlo es mejorando la cuestion de
> indices ¿?
>
no. a veces puedes reescribir las consultas de una mejor manera, y a
veces necesitas afinar las configuraciones de la base
> 1) SObre los indices:
> Hash :: Para condiciones tipo = (Pregunta: Por algun lado lei que no era recomendable usarlo puesto que se podian corromper algunos datos.. que tan
> cierto es esto ¿? y ademas tambien esta el hecho de que ocupan mucho
> mas espacio que el tipo BTree)
nunca uses hash... no es cierto que se corrompan de la nada. pero no
estan protegidos por el WAL lo que hace que se puedan corromper si la
base llegara a caerse y hubiera habido actividad en indices hash que no
puede reconstruir (porque esa reconstruccion la hace desde el WAL)
> B-Tree :: Para las demas condiciones
>
btree para operaciones normales (< <= = >= >), gist para otras
> Bueno entonces el uso de indices es la unica forma de mejorar la performance de un select o hay otras formas ¿?
>
no
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-07-18 18:08:49 | Re: PostgreSQL y SAN |
Previous Message | Alvaro Herrera | 2011-07-17 02:15:47 | Re: Problema con Ãndice y búsqueda . |