I wrote:
> Hmm. We could possibly fix this by having planagg.c do a completely
> separate planner run for each aggregate, wherein it actually does build
> the "equivalent" query
> SELECT col FROM tab WHERE existing-quals AND col IS NOT NULL
> ORDER BY col ASC/DESC LIMIT 1
> and plan that. That'd be less efficient than the current way,
> especially for cases where there are multiple aggregates, because there
> would be some duplication of processing between the per-aggregate
> planner runs and the main one. But since we can only do this
> optimization for rather simple queries anyway, maybe it wouldn't matter
> much.
I studied the code some more, and I think this probably can be made to
work. The basic idea is to have preprocess_minmax_aggregates build
simplified queries like the above (working by modifying the query tree
that exists at the point where it's called) and call query_planner on
them. Save aside the resulting path data, then let the regular planning
process continue. When optimize_minmax_aggregates is called, see
whether the regular plan is cheaper than the sum of the path costs.
If not, use the paths to construct a replacement plan, same as now.
The reason this should work is that query_planner() embodies pretty
much all the useful processing that happens between
preprocess_minmax_aggregates and optimize_minmax_aggregates --- the
other code in that stretch is mostly about grouping, which would disable
the minmax optimization anyway. So no important steps will get left
out. Of course, this introduces still more coupling between planagg.c
and planner.c, but I think that's probably tolerable. The main
objection to this approach is having to do all the index analysis
N+1 times for an N-aggregate query. I don't see any practical
alternative though if we want to make use of indexes that wouldn't be
used without the IS NOT NULL clause.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
