From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Joel Jacobson <joel(at)compiler(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <akorotkov(at)postgresql(dot)org> |
Subject: | Re: jsonb subscripting assignment performance |
Date: | 2021-04-14 16:52:59 |
Message-ID: | CAPpHfdsFWRW-54TuwwQJcZsS=gC7OKgaeN=SAUW22qjGnjDMXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 14, 2021 at 10:57 AM Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
> > sure - there is big room for optimization. But this patch was big enough
> > without its optimization. And it was not clean, if I will be committed or
> > not (it waited in commitfest application for 4 years). So I accepted
> > implemented behaviour (without inplace update). Now, this patch is in core,
> > and anybody can work on others possible optimizations.
>
> Right, jsonb subscripting deals mostly with the syntax part and doesn't
> change internal jsonb behaviour. If I understand the original question
> correctly, "in-place" here means updating of e.g. just one particular
> key within a jsonb object, since jsonb_set looks like an overwrite of
> the whole jsonb. If so, then update will still cause the whole jsonb to
> be updated, there is no partial update functionality for the on-disk
> format. Although there is work going on to optimize this in case when
> jsonb is big enough to be put into a toast table (partial toast
> decompression thread, or bytea appendable toast).
+1
------
Regards,
Alexander Korotkov
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-04-14 17:17:33 | Re: pg_amcheck contrib application |
Previous Message | Justin Pryzby | 2021-04-14 16:42:53 | Re: Possible typo/unclear comment in joinpath.c |