Re: Ordering behavior for aggregates

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Ordering behavior for aggregates
Дата
Msg-id 2331607.1670944414@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Ordering behavior for aggregates  (Ronan Dunklau <ronan.dunklau@aiven.io>)
Ответы Re: Ordering behavior for aggregates  (Ronan Dunklau <ronan.dunklau@aiven.io>)
Список pgsql-hackers
Ronan Dunklau <ronan.dunklau@aiven.io> writes:
> Le mardi 13 décembre 2022, 14:05:10 CET Vik Fearing a écrit :
>> On 12/13/22 13:55, Magnus Hagander wrote:
>>> On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing <vik@postgresfriends.org> 
>>> wrote:
>>>> However, it is completely useless for things like AVG() or SUM().  If
>>>> you include it, the aggregate will do the sort even though it is neither
>>>> required nor desired.

> I'm not sure about this. For AVG and SUM, if you want reproducible results 
> with floating point numbers, you may want it.

Yeah, I was about to mention the floating-point issue.  IIRC, we went
over exactly this ground when we introduced aggregate ORDER BY, and
decided that it was not our business to legislate whether particular
aggregates need ordering or not.  We don't try to second-guess users'
inclusion of ORDER BY in subqueries either, and that's just about
the same thing.  (Indeed, if you're feeding the subquery output to
an aggregate, it's exactly the same thing.)

Accordingly, I find nothing at all attractive in this proposal.
I think the main thing it'd accomplish is to drive users back to
the bad old days of ordering-by-subquery, if they have a requirement
we failed to account for.

            regards, tom lane



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

Предыдущее
От: Antonin Houska
Дата:
Сообщение: Re: refactor ExecGrant_*() functions
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Perform streaming logical transactions by background workers and parallel apply