David Rowley <dgrowleyml@gmail.com> writes:
> Waking up this old thread again. If you don't have a copy, the entire
> thread is in [1].
> The remaining item that seemed to cause this patch to be rejected was
> raised in [2].
Hmm. My estimate of the percentages of users who will be pleased or
not hasn't really changed since [2]. Also, realizing that you can't
apply these aggregates to extremely large input sets, I wonder just how
much it buys to be able to parallelize them. So I still put this patch
in the category of "just because we can doesn't mean we should".
Now as against that, if the underlying relation scan is parallelized
then you already have unpredictable input ordering and thus unpredictable
aggregate results. So anyone who cares about that has already had
to either disable parallelism or insert an ORDER BY somewhere, and
either of those fixes will still work if the aggregates support
parallelism. Hence, I'm not going to fight hard if you really want
to do it. But I remain unconvinced that the cost/benefit tradeoff
is attractive.
regards, tom lane