Re: jsonb subscripting assignment performance

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, akorotkov(at)postgresql(dot)org
Subject: Re: jsonb subscripting assignment performance
Date: 2021-04-14 07:50:02
Message-ID: 0c10d42e-2ce0-4e01-a325-058993dc410f@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 14, 2021, at 09:20, Pavel Stehule 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.

Thanks for explaining.

Do we a rough idea on how in-place could be implemented in a non-invasive non-controversial way that ought to be accepted by the project, if done right? Or are there other complicated problems that needs to be solved first?

I'm asking because I could be interested in working on this, but I know my limitations when it comes to C, so I want to get an idea on if it should be more or less straightforward, or if we already know on beforehand it would require committer-level expertise of the PostgreSQL code base for any realistic chance of being successful.

/Joel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2021-04-14 07:57:33 Re: jsonb subscripting assignment performance
Previous Message osumi.takamichi@fujitsu.com 2021-04-14 07:48:16 RE: Truncate in synchronous logical replication failed