From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Daniel Gustafsson <daniel@yesql.se>
Cc: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: partition routing layering in nodeModifyTable.c
Date: Fri, 23 Oct 2020 10:04:31 +0300
Message-ID: <7489c360-ccaf-b2ac-ca56-d68b1caf02db@iki.fi> (raw)
In-Reply-To: <CA+HiwqHwtTQ_pSnxTErdSV11yxeZ8O2akkAtYnqST=E3McmdnQ@mail.gmail.com>
References: <20201017155429.GA9862@alvherre.pgsql>
<1d6516c6-9766-3d35-9acd-6358aa51a1ce@iki.fi>
<CA+HiwqEs18rLT4OivHtLhUOZ1XU5qFdTyMk8qG7yEC8OJ49G_A@mail.gmail.com>
<CA+HiwqHwtTQ_pSnxTErdSV11yxeZ8O2akkAtYnqST=E3McmdnQ@mail.gmail.com>
On 22/10/2020 16:49, Amit Langote wrote:
> On Tue, Oct 20, 2020 at 9:57 PM Amit Langote <amitlangote09@gmail.com> wrote:
>> On Mon, Oct 19, 2020 at 8:55 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> It's probably true that there's no performance gain from initializing
>>> them more lazily. But the reasoning and logic around the initialization
>>> is complicated. After tracing through various path through the code, I'm
>>> convinced enough that it's correct, or at least these patches didn't
>>> break it, but I still think some sort of lazy initialization on first
>>> use would make it more readable. Or perhaps there's some other
>>> refactoring we could do.
>>
>> So the other patch I have mentioned is about lazy initialization of
>> the ResultRelInfo itself, not the individual fields, but maybe with
>> enough refactoring we can get the latter too.
>
> So, I tried implementing a lazy-initialization-on-first-access
> approach for both the ResultRelInfos themselves and some of the
> individual fields of ResultRelInfo that don't need to be set right
> away. You can see the end result in the attached 0003 patch. This
> slims down ExecInitModifyTable() significantly, both in terms of code
> footprint and the amount of work that it does.
Have you done any performance testing? I'd like to know how much of a
difference this makes in practice.
Another alternative is to continue to create the ResultRelInfos in
ExecInitModify(), but initialize the individual fields in them lazily.
Does this patch become moot if we do the "Overhaul UPDATE/DELETE
processing"?
(https://www.postgresql.org/message-id/CA%2BHiwqHpHdqdDn48yCEhynnniahH78rwcrv1rEX65-fsZGBOLQ%40mail.g...)?
- Heikki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: hlinnaka@iki.fi, amitlangote09@gmail.com, alvherre@alvh.no-ip.org, daniel@yesql.se, etsuro.fujita@gmail.com, andres@anarazel.de
Subject: Re: partition routing layering in nodeModifyTable.c
In-Reply-To: <7489c360-ccaf-b2ac-ca56-d68b1caf02db@iki.fi>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox