"Dann Corbit" <DCorbit@connx.com> writes:
> Is this a poorly designed hack:
> Select max(expression) from <join> where <filter>
Well, to start with, any nonempty WHERE probably invalidates the
optimization, and I doubt it works if there's a join rather than a
single table involved. But you're just handwaving --- the devil is in
the details. How will you identify which aggregates are MIN and MAX
(no, I don't like the idea of relying on the names; remember we have
an extensible set of aggregates)? What will you do when there are
multiple aggregates in the command --- or more generally, how complex a
context for the aggregate call are you going to be able to support?
Where exactly is this transformation going to occur in the planning
pipeline, and how many cycles will we waste checking for the possible
transform in cases where it doesn't apply? Questions like these are
where we've gotten bogged down in the past. You might care to consult
the pgsql-hackers archives for past discussions.
regards, tom lane
