Re: On query rewrite - Mailing list pgsql-hackers

From Tom Lane
Subject Re: On query rewrite
Date
Msg-id 21975.1085755100@sss.pgh.pa.us
Whole thread Raw
In response to Re: On query rewrite  (Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>)
Responses Re: On query rewrite
List pgsql-hackers
Sailesh Krishnamurthy <sailesh@cs.berkeley.edu> writes:
> What about things like:

> 1. DISTINCT PULLUP (Where you realize that you don't have to have an
> explicit duplicate elimination operation because of what's done in the
> subquery)
> 2. DISTINCT pushdown (when a dup elim. can be pushed down if the upper
> querytree is performign DISTINCT set operations (UNION, INTERSECT etc)
> 3. Discarding DISTINCT in a subquery because the upper query uses the
> subquery with existential quantification

Our bottom-up planning approach isn't very conducive to #2 or #3, but we
do make a stab at #1.  See create_unique_path() and is_distinct_query()
in optimizer/util/pathnode.c (note this is new code in CVS tip, 7.4 did
not have any such optimization).

> In general, I'm trying to understand all the transformations that
> pgsql will try to do .. I'm not trying to figure out plan enumeration
> for basic boxes (simple query tree).

This particular issue is handled as part of our Path enumeration
mechanism, but the more hard-wired sorts of transformations that you are
asking about live mostly in optimizer/prep/* and plan/planner.c.  In
particular you probably want to look at prepjointree.c and prepqual.c.
(Note prepqual also looks considerably different in CVS tip than in
prior releases.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Mike Mascari
Date:
Subject: Re: Win32, PITR, nested transactions, tablespaces
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_dump --comment?