From: Tom Lane <tgl@sss.pgh.pa.us>
To: sf_postgresql@informationsoftworks.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17896: xmlagg exponentially slower than string_agg
 equivalent
In-reply-to: <17896-f4bf54f99b6a3089@postgresql.org>
References: <17896-f4bf54f99b6a3089@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Fri, 14 Apr 2023 15:12:59 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1701647.1681569942.1@sss.pgh.pa.us>
Date: Sat, 15 Apr 2023 10:45:42 -0400
Message-ID: <1701648.1681569942@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1701648.1681569942%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> Also, while string_agg() seems to scale linearly (O(n)), xmlagg() seems to
> scale somewhat steeper (O(n^2)?).

Yeah, string_agg was optimized long ago to avoid repeat data copying,
but xmlagg hasn't been.

It looks like xmlagg doesn't make any direct use of libxml, which suggests
that this wouldn't be terribly hard to fix if somebody were motivated
to try.  The xml type is a bit of a development backwater though ...

			regards, tom lane