Re: MAX/MIN optimization via rewrite (plus query rewrites generally)

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

In response to

Responses

Browse pgsql-hackers by date

  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.*