Re: On query rewrite - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: On query rewrite
Date
Msg-id 20040528045214.GB14710@dcc.uchile.cl
Whole thread Raw
In response to Re: On query rewrite  (Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>)
List 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.



pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: hash, rtree and gist ScanLists
Next
From: Tom Lane
Date:
Subject: Re: On query rewrite