Re: [HACKERS] PoC: Grouped base relation - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] PoC: Grouped base relation
Date
Msg-id CAKJS1f_U4ccaYvMH=Gie5utua+cXWGTk8Eb9Vh9A8TBmWNzm0Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PoC: Grouped base relation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] PoC: Grouped base relation  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 19 January 2017 at 07:32, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

I had assumed that the combine function which combines a large array
or a large string would not be any cheaper than doing that
incrementally with the transfn. Of course some of this would happen in
parallel, but it still doubles up some of the memcpy()ing, so perhaps
it would be slower? ... I didn't ever get a chance to test it.


-- David Rowley                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (wasChanged SRF in targetlist handling)
Next
From: Justin Pryzby
Date:
Subject: [HACKERS] smallint out of range EXECUTEing prepared statement