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

From: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
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
Date: 2004-11-24 20:26:12
Message-ID: 41A4EE64.10601@coretech.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I think a summary of where the discussion went might be helpful
(especially for me after a week or so away doing perl).

There were a number of approaches suggested, which I will attempt to
summarize in a hand wavy fashion - (apologies for any misrepresentation
caused):

i) Rewrite max/min querys using order by in presence of a suitable index.

ii) Provide alternate (i.e rewritten) querys for consideration along
with the
original, letting the planner use its costing methods to choose as
usual.

iii) Provide alternate plans based on presence of certain aggregate types in
the query, letting the planner use its costing methods to choose as
usual.

iv) Create short-cut evaluations for certain aggregates that don't actually
need to see all the (to-be aggregated) data.

v) Create a mechanism for defining per-aggregate optimization operators.

Note that some of these ideas may overlap one another to some extent.

Some critiques of the various approaches are:

i) Too simple, rewrite may not be better than original, only simple
queries
can be handled this way. Probably reasonably easy to implement.

ii) Simple queries will be well handled, but very complex transformations
needed to handle even slightly more complex ones. Probably medium ->
difficult to implement.

iii) Rules for creating alternate plans will mimic the issues with ii).
Probably medium -> difficult to implement.

iv) May need different short cuts for each aggregate -> datatype
combination.
Implies conventional > and < operators, or the existence of similar
use definable ones (or a way of finding suitable ones). Guessing medium
to implement.

v) Is kind of a generalization of iv). The key areas of difficulty are the
specification of said optimization operators and the definition of
an API
for constructing/calling them. Guessing difficult to implement.

I am leaning towards ii) or iv) as the most promising approaches - what
do people think?

regards

Mark

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Hallgren 2004-11-24 23:16:45 Intermittent bug
Previous Message Barry Lind 2004-11-24 17:49:40 Re: [JDBC] Strange server error with current 8.0beta driver