Re: Parallel Aggregates for string_agg and array_agg
От | Tomas Vondra |
---|---|
Тема | Re: Parallel Aggregates for string_agg and array_agg |
Дата | |
Msg-id | 73ea70fa-9ada-deb5-549e-02fa2f0969c6@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Parallel Aggregates for string_agg and array_agg (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: Parallel Aggregates for string_agg and array_agg
|
Список | pgsql-hackers |
On 03/29/2018 03:09 PM, David Rowley wrote: > On 30 March 2018 at 02:00, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: >> On 03/29/2018 05:49 AM, David Rowley wrote: >>> Attached is v9, which is based on Tom's v8 but includes the new tests >>> and I think the required fix to disable use of the serial/deserial >>> function for array_agg(). >>> >> >> I have only looked at the diff, but it seems fine to me (in the sense >> that it's doing the right checks to disable parallelism only when really >> needed). >> >> FWIW I wonder if we might simply fallback to input/output functions when >> the send/receive functions are not available. Not sure it's worth it. > > I think it's a corner case to have a type without send/receive, but I > might just be lacking imagination. > Not sure, but it's a valid case. OTOH we probably don't need to obsess about handling it perfectly. > I meant to mention earlier that I coded > agg_args_have_sendreceive_funcs() to only check for send/receive > functions. Really we could allow a byval types without send/receive > functions, since the serial/deserial just send the raw datums in that > case, but then the function becomes > agg_byref_args_have_sendreceive_funcs(), which seemed a bit obscure, > so I didn't do that. Maybe I should? > I'd do that. Not sure the function name needs to change, but perhaps agg_args_support_sendreceive() would be better - it covers both byref types (which require send/receive functions) and byval (which don't). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: