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 05:25:34
Message-ID: 14650.1085721934@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu> writes:
> Now my next question is more subtle ..

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

That particular choice is not --- we do it if we can, else not.
Comparisons between different alternatives are always handled by
computing cost estimates and choosing the lowest. In most cases
that's mechanized as generating Paths for all alternatives and letting
the fittest Path survive. I think there are one or two places where
there's a more hard-wired cost comparison, because there are only a
couple of possibilities.

> 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

Yes --- the rewriter generally does not have as much semantic or
statistical information available as the planner does.

> Another question about regular RULE processing .. suppose after
> applying a rule the resultant query tree is eligible for another rule,
> does pgsql's rule system keep iterating over and over until it reaches
> a fixed point or is there some heuristic in operation (just apply the
> rules twice ..) ?

As of recent releases it expands till it runs out of rules or detects
infinite recursion. You may be looking at a version that had a
give-up-after-N-levels heuristic instead of actual recursion detection.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-05-28 05:32:30 Re: Win32, PITR, nested transactions, tablespaces
Previous Message Christopher Kings-Lynne 2004-05-28 05:00:46 Re: hash, rtree and gist ScanLists