Re: [SQL] Good Optimization - Mailing list pgsql-sql

From secret
Subject Re: [SQL] Good Optimization
Date
Msg-id 37933011.CB0F3E76@kearneydev.com
Whole thread Raw
In response to Re: [SQL] Good Optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [SQL] Good Optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-sql
Tom Lane wrote:

> secret <secret@kearneydev.com> writes:
> >     There is a simple way to optimize SQL queries involving joins to
> > PostgreSQL that I think should be handled by Postgre?  If one is joining
> > a tables a,b on attribute "x" and if one has something like x=3 then it
> > helps A LOT to say: a.x=3 and b.x=3 in addition to saying a.x=b.x ...
> > The example below shoulds the radical speed gain of doing this, and I
> > think it isn't something real obvious to most people...
>
> How much *actual* speedup is there?  I don't trust the optimizer's
> numbers as anything more than relative measures ;-)
>
> I'm a bit surprised that you are getting a nested-loop plan and not
> a merge or hash join.  With a merge join, at least, there ought not be
> a large difference from providing the additional qual clause (I think).
> What Postgres version are you using?
>
>                         regards, tom lane
   The actual performance difference is HUGE.  Hours vs minutes or Minutes vs
Seconds...

David Secret
MIS Director
Kearney Development Co., Inc.




pgsql-sql by date:

Previous
From: Herouth Maoz
Date:
Subject: Re: [SQL] Re: [HACKERS] Counting bool flags in a complex query
Next
From: secret
Date:
Subject: Re: [SQL] Good Optimization