Re: On query rewrite - Mailing list pgsql-hackers

From Tom Lane
Subject Re: On query rewrite
Date
Msg-id 14650.1085721934@sss.pgh.pa.us
Whole thread Raw
In response to Re: On query rewrite  (Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>)
Responses Re: On query rewrite  (Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>)
List pgsql-hackers
Sailesh Krishnamurthy <sailesh@cs.berkeley.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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: On query rewrite
Next
From: Tom Lane
Date:
Subject: Re: Win32, PITR, nested transactions, tablespaces