Re: Ayuda sobre joins

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/

In response to

Browse pgsql-es-ayuda by date

  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