Re: Proposal: Pre ordered aggregates, default ORDER BY clause for aggregates - median support
От | Tom Lane |
---|---|
Тема | Re: Proposal: Pre ordered aggregates, default ORDER BY clause for aggregates - median support |
Дата | |
Msg-id | 5358.1261345192@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: Pre ordered aggregates, default ORDER BY clause for aggregates - median support (Dimitri Fontaine <dfontaine@hi-media.com>) |
Список | pgsql-hackers |
Dimitri Fontaine <dfontaine@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 itsounds right on spot (general enough without being over engineering). I guess it would give the planner the same informationas 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 aggregatedefinition 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
В списке pgsql-hackers по дате отправления: