From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Kirkwood <markir(at)coretech(dot)co(dot)nz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
Date: | 2004-11-11 00:18:59 |
Message-ID: | 2089.1100132339@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Kirkwood <markir(at)coretech(dot)co(dot)nz> writes:
> I am looking at implementing this TODO item. e.g. (max case):
> My initial thoughts revolved around extending the existing RULE system
> to be able to handle more general types of rewrite - like conditionals
> in SELECT rules and rewrites that change elements of the query other
> than the target relation.
The rule rewriter is almost certainly the wrong place, because it has
only the most superficial understanding of a query's semantics.
Doing this processing there would require re-inventing (or at least
duplicating the execution of) a lot of the planner's query analysis
work.
My thoughts would run towards doing this after the prepqual and
prepjointree steps (probably somewhere in grouping_planner). Even there
is a bit early since you'd have to duplicate plancat.c's extraction of
information about related indexes; but possibly it'd be reasonable to
move the add_base_rels_to_query() call out of query_planner and do it in
grouping_planner.
A more radical way of handling it would be to detect the relevance of an
indexscan in indxpath.c and generate a special kind of Path node; this
would not generalize to other sorts of things as you were hoping, but
I'm unconvinced that the mechanism is going to be very general-purpose
anyway. The major advantage is that this would work conveniently for
comparing the cost of a rewritten query to a non-rewritten one.
How are you planning to represent the association between MIN/MAX and
particular index orderings in the system catalogs?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ramy M. Hassan | 2004-11-11 00:44:08 | Re: sp-gist porting to postgreSQL |
Previous Message | Tom Lane | 2004-11-10 23:42:25 | Re: CREATE or REPLACE function pg_catalog.* |