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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
