Re: two seperate queries run faster than queries ORed - Mailing list pgsql-performance

From Stephan Szabo
Subject Re: two seperate queries run faster than queries ORed
Date
Msg-id 20040322113002.D62908@megazone.bigpanda.com
Whole thread Raw
In response to Re: two seperate queries run faster than queries ORed together  (Joseph Shraibman <jks@selectacast.net>)
Responses Re: two seperate queries run faster than queries ORed together  (Joseph Shraibman <jks@selectacast.net>)
Re: two seperate queries run faster than queries ORed  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Mon, 22 Mar 2004, Joseph Shraibman wrote:

> Tom Lane wrote:
> > Joseph Shraibman <jks@selectacast.net> writes:
> >
> >>No, pkey is not the primary key in this case. The number of entries in u
> >>that have pkey 260 and not boolfield is 344706.
> >
> >
> > ... and every one of those rows *must* be included in the join input,
>
> *If* you use one big join in the first place.  If postgres ran the query
> to first get the values with status == 3 from u, then ran the query to
> get the entries from d, then combined them, the result would be the same
> but the output faster.  Instead it is doing seq scans on both tables and

Well, you have to be careful on the combination to not give the wrong
answers if there's a row with u.status=3 that matches a row d.status=3.

pgsql-performance by date:

Previous
From: Joseph Shraibman
Date:
Subject: Re: two seperate queries run faster than queries ORed together
Next
From: Joseph Shraibman
Date:
Subject: Re: two seperate queries run faster than queries ORed together