Chris Browne <cbbrowne@xxxxxxx> writes: > stark@xxxxxxxxxxxxxxxx (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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
