Dimitri Fontaine <dfonta...@hi-media.com> writes:
> Le 20 déc. 2009 à 22:08, Tom Lane a écrit :
>> Another risk is that features added now might preclude adding others
>> later.
> Now, I have no idea if augmenting the aggregate properties with an optional
> sorting step is the right approach, but it sounds right on spot (general
> enough without being over engineering). I guess it would give the planner the
> same information as if the user did type the extra order by himself, so I'm
> not sure how much your remarks would apply?
> I mean we already have explicit user ordering in aggregates at call site,
> adding the exact same information in the aggregate definition itself surely
> isn't going to be such a change there?
It's not obvious to me that this feature is better than others that
might apply in the same general area, eg the existing min/max
optimization. Since (to repeat myself) we have no field experience
with ordered aggregate inputs, assuming we know what the next extension
should be in this area seems a bit premature.
Also, you're conveniently ignoring my point about how optimization
should probably be the next area of focus here. Right now, there
is really little if any value in having this feature, because a
median aggregate could sort internally and not be any more or less
efficient than having nodeAgg do it. Once we have an optimization
framework there might be some advantage there, but we should not
complicate matters with second-order features before we have that.
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
