Re: CREATE AGGREGATE array_cat - Mailing list pgsql-hackers

From Andres Freund
Subject Re: CREATE AGGREGATE array_cat
Date
Msg-id 20201119015212.kwz6widasa4pf7ah@alap3.anarazel.de
Whole thread Raw
In response to Re: CREATE AGGREGATE array_cat  (Chapman Flack <chap@anastigmatix.net>)
List 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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: remove spurious CREATE INDEX CONCURRENTLY wait
Next
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Disable WAL logging to speed up data loading