| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PG19] jsonb_object_agg as a window function returns stale values |
| Date: | 2026-10-14 15:10:28 |
| Message-ID: | CAAKRu_Y-MRtDRzjUQm9YNCtyiUpuegXrb=BT-xxM0=t=r7FdpA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Oct 14, 2026 at 12:03 AM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> > One alternative could be to use the extra palloc/memcpy only when
> > skip_nulls is true, after fixing uniqueifyJsonbObject to renumber
> > the pairs.
>
> v2 does that, with a narrower test for the copy. Removing null pairs
> from the state is harmless unless unique_keys is also set, since the
> dedup loop skips nulls before it looks for duplicates. So 0001 copies
> the pairs only for jsonb_object_agg_unique_strict.
>
> With your benchmark on a non-assert build, HEAD and v2 both take about
> 10 ms of backend CPU, and v1 takes 5.6 s :( .
>
> > (Independently of all this, the documentation for the json-object
> > aggregates is seriously awful.
>
> 0003 is a try at that. It says which value wins for a repeated key,
> and that null values are dropped first but still count in the unique
> check.
Should this have a PG 19 open item?
- Melanie
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-10-14 15:14:50 | Re: [PG19] jsonb_object_agg as a window function returns stale values |
| Previous Message | Melanie Plageman | 2026-10-14 15:08:40 | Re: PG19: two RI fast-path issues found while testing the batching revert |