Re: On query rewrite

From: Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 08:01:36
Message-ID: mjqlljdj7z3.fsf@cs.berkeley.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

>> Are these alternatives (pulling up vs not pulling up
>> subqueries) considered in different plans ?

Tom> That particular choice is not --- we do it if we can, else
Tom> not. Comparisons between different alternatives are always
Tom> handled by computing cost estimates and choosing the lowest.

Thank you Tom (and Alvarro)

So I've understood pull_up_subqueries (called SELECT MERGE in
Starburst).

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

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).

--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2004-05-28 09:16:21 Re: tablespaces and DB administration
Previous Message Tatsuo Ishii 2004-05-28 07:51:07 Re: Nested xacts: looking for testers and review