Re: How to push predicate down

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: salah jubeh <s_jubeh(at)yahoo(dot)com>
Cc: Volodymyr Kostyrko <c(dot)kworr(at)gmail(dot)com>, pgsql <pgsql-general(at)postgresql(dot)org>
Subject: Re: How to push predicate down
Date: 2012-01-27 00:54:11
Message-ID: 15060.1327625651@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I wrote:
> Hmm. The code explicitly won't push conditions down through an EXCEPT:
> * 3. If the subquery contains EXCEPT or EXCEPT ALL set ops we cannot push
> * quals into it, because that could change the results.
> I remember coming to the conclusion that this is safe for
> UNION/INTERSECT but not EXCEPT, but right at the moment I'm not sure why
> I thought that --- it seems like a qual that suppresses specific rows
> should suppress all matching copies.

I dug in the archives and found the discussion that led up to the
current behavior; see thread starting here
http://archives.postgresql.org/pgsql-hackers/2002-08/msg00041.php

The issue is that rows that are "equal" according to the rules used by
UNION/INTERSECT/EXCEPT may nonetheless be distinguishable to the
expression in the upper WHERE clause, and if that's the case, pushing
down the WHERE can lead to provably incorrect results. So the behavior
is correct, or at least very difficult to improve on, as it stands.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-01-27 02:15:32 Re: Optimizing Queries Joining Several Views
Previous Message Scott Marlowe 2012-01-27 00:27:04 Re: Preventing access temporarily.