Re: Aggregates with non-commutative transition functions
От
Tom Lane
Тема
Re: Aggregates with non-commutative transition functions
Дата
Msg-id
16193.1045323727@sss.pgh.pa.us
Ответ на
Re: Aggregates with non-commutative transition functions (Emmanuel Charpentier)
Список
Дерево обсуждения
Aggregates with non-commutative transition functions Emmanuel Charpentier <charpent@bacbuc.dyndns.org>
Re: Aggregates with non-commutative transition functions Tom Lane <tgl@sss.pgh.pa.us>
Re: Aggregates with non-commutative transition functions Emmanuel Charpentier <charpent@bacbuc.dyndns.org>
Re: Aggregates with non-commutative transition functions Tom Lane <tgl@sss.pgh.pa.us>
Re: Aggregates with non-commutative transition functions Tom Lane <tgl@sss.pgh.pa.us>
Re: Aggregates with non-commutative transition functions Emmanuel Charpentier <charpent@bacbuc.dyndns.org>
Re: Aggregates with non-commutative transition functions Tom Lane <tgl@sss.pgh.pa.us>
Re: Aggregates with non-commutative transition functions Emmanuel Charpentier <charpent@bacbuc.dyndns.org>
Emmanuel Charpentier writes: > Since the stability of the sort is an issue but for this quite specific > case, one could envision a flag to "CREATE AGGREGATE", signalling the > planner the fact that the transition function isn't commutative, hence the > need to use a stable version of sort() Actually, I would think that you'd really prefer that the system not run a sort step at all. As of CVS tip, if the planner decides to use hash-based aggregation for your query then there wouldn't be any pre-sort. But there's no guarantee it will do that. A better alternative is to get the planner to notice in the context of the outer query that the inner query's result is already sorted by recnum. Then it wouldn't do the unwanted sort in any case. This has been on the to-do list for awhile, but hasn't risen to the top ... regards, tom lane
В списке pgsql-general по дате отправления