Re: two seperate queries run faster than queries ORed together

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joseph Shraibman <jks(at)selectacast(dot)net>
Cc: Richard Huxton <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: two seperate queries run faster than queries ORed together
Date: 2004-03-22 18:24:19
Message-ID: 6875.1079979859@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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,
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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Joseph Shraibman 2004-03-22 19:00:30 Re: two seperate queries run faster than queries ORed together
Previous Message Joseph Shraibman 2004-03-22 17:55:31 Re: two seperate queries run faster than queries ORed together