On Tue, Jan 17, 2017 at 11:33 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > I don't think aggcombinefn isn't there because we couldn't write it > for array_agg() or string_agg(). I guess, it won't be efficient to > have those aggregates combined across parallel workers.
I think there are many cases where it would work fine. I assume that David just didn't make it a priority to write those functions because it wasn't important to the queries he wanted to optimize. But somebody can submit a patch for it any time and I bet it will have practical use cases. There might be some performance problems shoving large numbers of lengthy values through a shm_mq, but we won't know that until somebody tries it. > Also, the point is naming that kind of function as aggtransmultifn > would mean that it's always supposed to multiply, which isn't true for > all aggregates. TransValue * integer = newTransValue is well-defined for any aggregate. It's the result of aggregating that TransValue with itself a number of times defined by the integer. And that might well be significantly faster than using aggcombinefn many times. On the other hand, how many queries just sit there are re-aggregate the same TransValues over and over again? I am having trouble wrapping my head around that part of this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
