Re: [HACKERS] Parallel Aggregation support for aggregate functions that use transitions not implemented for array_agg

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Parallel Aggregation support for aggregate functions that use transitions not implemented for array_agg
Дата
Msg-id 17091.1496808195@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Parallel Aggregation support for aggregate functionsthat use transitions not implemented for array_agg  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] Parallel Aggregation support for aggregate functionsthat use transitions not implemented for array_agg  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2017-06-06 23:32:53 -0400, Peter Eisentraut wrote:
>> I'm not sure how you would parallelize these, since in most uses you
>> want to have a deterministic output order.

> Unless you specify ORDER BY you don't really have that anyway, consider
> hash-aggregation.  If you want deterministic order, you really need an
> ORDER BY inside the aggregate.

Hash aggregation does not destroy the property that array_agg/string_agg
will produce results whose components appear in the order that the
subquery emitted them in.  It only causes the various aggregate results
in a GROUP BY query to themselves appear in random order.

Now you could argue that the subquery might've gotten parallelized and
emitted its outputs in some random order, so doing the same thing one
level further up changes nothing.  But you can't defend this on this
basis that it was historically unpredictable, because it wasn't.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Fix tab-completion of ALTER SUBSCRIPTION SET PUBLICATION
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Parallel Aggregation support for aggregate functionsthat use transitions not implemented for array_agg