Re: CREATE AGGREGATE array_cat

From: Andres Freund <andres(at)anarazel(dot)de>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Vlad Bokov <vlad(at)razum2um(dot)me>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: CREATE AGGREGATE array_cat
Date: 2020-11-19 01:52:12
Message-ID: 20201119015212.kwz6widasa4pf7ah@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-11-18 19:54:52 -0500, Chapman Flack wrote:
> On 11/18/20 19:46, David G. Johnston wrote:
>
> > I doubt there is any substantial resistance to including such a function
> > but it would have to be written in C.
>
> Would anything have to be written at all, save the CREATE AGGREGATE
> suggested in the original message, using the existing array_cat as the
> state transition function?

Using array_cat() as the transition function essentially is O(N^2). And
I don't think there's a good way to solve that in array_cat() itself, at
least not compared to just using similar logic to array_agg.

> I suppose one might add an optimization to the existing array_cat to
> detect the aggregate case, and realize it could clobber its left argument.
> (But I'm not sure how much that would save, with arrays.)

I don't immediately see how clobbering the left arg would work
reliably. That's easy enough for in-place modifications of types that
have a fixed width, but for an arbitrary width type that's much
harder. You could probably hack something together by inquiring about
the actual memory allocation size in aset.c etc, but that's pretty ugly.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message osumi.takamichi@fujitsu.com 2020-11-19 02:07:54 RE: Disable WAL logging to speed up data loading
Previous Message Michael Paquier 2020-11-19 01:51:26 Re: remove spurious CREATE INDEX CONCURRENTLY wait