Chris Browne <cbbrowne@acm.org> writes:
> stark@enterprisedb.com (Gregory Stark) writes:
>> In theory we can't promise anything about future versions of
>> Postgres but there are lots of people doing this already so if ever
>> this was lost there would probably be some new explicit way to
>> achieve the same thing.
> Is there not some risk that the query planner might choose to do
> hash-based accumulation could discard the subquery's ordering?
Hash aggregation doesn't change the order in which input rows are fed to
any one aggregate; it only results in nominally-independent aggregate
functions being computed in parallel. If you tried to write an
aggregate function that had hidden private state and wasn't re-entrant,
it would likely fail under hash aggregation; but aggregate functions
that "play by the rules" by keeping all their state in the declared
state object will work fine.
The long and the short of it is that we are very well aware that people
depend on this behavior, and we are not likely to break it.
regards, tom lane