| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | sf_postgresql(at)informationsoftworks(dot)com |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17896: xmlagg exponentially slower than string_agg equivalent |
| Date: | 2023-04-15 14:45:42 |
| Message-ID: | 1701648.1681569942@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2023-04-15 15:17:09 | Re: BUG #17897: Crash on assignment to array of constraint-less domain over composite type |
| Previous Message | PG Bug reporting form | 2023-04-15 03:45:08 | BUG #17898: Build failure when strip is LLVM's version |