Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group