From: | Javier Chávez B(dot) <jchavezb(at)gmail(dot)com> |
---|---|
To: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
Cc: | mPerez mPerez <stylergarcia(at)gmail(dot)com>, pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: Ayuda sobre joins |
Date: | 2010-01-22 18:41:19 |
Message-ID: | ded64bba1001221041v19a1907ex6f058174bf6c9a24@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
On 1/22/10, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> wrote:
> 2010/1/22 mPerez mPerez <stylergarcia(at)gmail(dot)com>:
>> Hola a todos, quisiera que me ayuden de como es la manera mas eficiente de
>> sacar una consulta, si utilizando joins, subconsultas, etc.
>
> esa pregunta no tiene respuesta porque esta mal planteada y refleja
> poco conocimiento de como trabaja casi cualquier gestor de base de
> datos.
>
> en primer lugar; el SQL es un lenguaje de 4ta generación, lo que
> significa que tu solo debes preocuparte de cual es el resultado que
> quieres y es el gestor *y no tu* el que tiene la tarea de resolverlo
> de la manera mas eficiente.
>
> Debido a eso casi todo gestor, antes de ejecutar una consulta pasa por
> un proceso de optimización en el cual trata de determinar cual es la
> mejor manera de resolver la consulta que le hiciste; en el caso
> especifico de postgres normalmente ignorará el orden en que pongas las
> tablas en la clausula FROM (al menos en el caso de los INNER JOIN),
> tambien tratara de empujar las subconsultas hacia la consulta
> principal, no te permite indicar que indices debe usar o cosas como
> esa.
> La mayoría de las veces el gestor sabrá mejor que tu lo que hay que
> hacer (y antes de que digan que soy grosero, la razón por la que el
> gestor sabrá mejor que tu lo que hay que hacer es que el tiene
> estadisticas que tu no tienes, como cual es la tabla mas grande, cual
> tabla es mas probable que encuentre en memoria si alguna, cuales son
> los valores mas consultados, de que indices dispone, etc, etc, etc)
>
> En ocasiones el gestor es incapaz de determinar cual es la mejor
> manera de resolver la consulta y solo entonces vale la pena la
> intervención humana.
>
> Tratar de hacer eso antes de tiempo (es decir al armar la consulta la
> primera vez) cae en la categoria de "optimizacion adelantada" y eso mi
> amigo es la raiz de todos los males...
>
>
> Habiendo dicho todo eso, es obvio que tu consulta se resuelve con un
> join... no veo la necesidad de subconsultas por ahora, eso dejalo para
> el supuesto de que debas tratar de optimizar (y eso solo si consigues
> que el optimizador no mezcle las consultas de todos modos)
Excelente ! Jaime .. gracias! aunque no estoy en el hilo encontre
genial tu explicacion.. !
Slds.
Jc
--
Cumprimentos
jchavez
linux User #397972 on http://counter.li.org/
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2010-01-22 18:43:30 | Re: Problema al ejecutar el pgpool... |
Previous Message | Jaime Casanova | 2010-01-22 18:37:04 | Re: Ayuda sobre joins |