On Tue, Jan 17, 2017 at 11:33 PM, Ashutosh Bapat
<ashutosh.bapat@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
