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