Re: On query rewrite

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: sailesh(at)cs(dot)berkeley(dot)edu
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: On query rewrite
Date: 2004-05-28 14:38:20
Message-ID: 21975.1085755100@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2004-05-28 14:48:56 Re: pg_dump --comment?
Previous Message Mike Mascari 2004-05-28 14:23:47 Re: Win32, PITR, nested transactions, tablespaces