Re: On query rewrite

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: On query rewrite
Date: 2004-05-28 04:52:14
Message-ID: 20040528045214.GB14710@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 27, 2004 at 07:35:56PM -0700, Sailesh Krishnamurthy wrote:

> Anyway, thanks for the tips. I think I found what I'm looking for: the
> function is probably pull_up_subqueries .. and what it tries to do is
> check if a subquery is "simple" or not .. "simple" means not having
> Aggs or something more complicated. If that's the case, and if some
> NULLable conditions are safe then, the subquery gets pulled up -
> essentially, a subquery to join transformation.

Hmm, this code has been heavily hacked during the last few versions so
if you want to know the state of the art be sure to check a recent
version (for example if you don't see pull_up_IN_clauses() you are
missing some of the fun.)

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

Yes, AFAIU.

> Are more such transformations spread around the optimizer component ?

Yes, AFAIU.

> Is there any reason to have it integrated with the planner as opposed
> to having it be part of the rewrite component (apart from historical
> .. plus the code is solid and works etc.) ?

The current code uses cost estimation to determine whether to apply them
or not; in some situations they would lead to a more expensive (==
slower) plan, or to using huge amounts of memory (for example hash based
aggregation).

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Dios hizo a Adán, pero fue Eva quien lo hizo hombre.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-05-28 05:00:46 Re: hash, rtree and gist ScanLists
Previous Message Bruce Momjian 2004-05-28 04:40:14 Re: Win32, PITR, nested transactions, tablespaces