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

From Tom Lane
Subject Re: two seperate queries run faster than queries ORed together
Date
Msg-id 6875.1079979859@sss.pgh.pa.us
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
List pgsql-performance
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,
regardless of its status value, because it might join to some d row that
has status=3.  Conversely, every single row of d must be considered in
the join because it might join to some u row with status=3.  So any way
you slice it, this query requires a large and expensive join operation,
no matter that there are only a few rows with the right status values in
the other table.

I'd rewrite the query if I were you.

            regards, tom lane

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