Stephan Szabo wrote:
> On Mon, 22 Mar 2004, Joseph Shraibman wrote:
>>Tom Lane wrote:
>>>Joseph Shraibman <jks(at)selectacast(dot)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.
Right you would have to avoid duplicates. The existing DISTINCT code
should be able to handle that.
In response to
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2004-03-22 20:44:09|
|Subject: Re: two seperate queries run faster than queries ORed |
|Previous:||From: Stephan Szabo||Date: 2004-03-22 19:32:30|
|Subject: Re: two seperate queries run faster than queries ORed|