Re: ModifyTable overheads in generic plans

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Subject: Re: ModifyTable overheads in generic plans
Date: 2020-09-14 03:51:33
Message-ID: CA+HiwqE4k1Q2TLmCAvekw+8_NXepbnfUOamOeX=KpHRDTfSKxA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

On Fri, Aug 7, 2020 at 9:26 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Tue, Aug 4, 2020 at 3:15 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > On Sat, Aug 1, 2020 at 4:46 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > > On Fri, Jun 26, 2020 at 8:36 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > > > 0001 and 0002 are preparatory patches.
> > >
> > > I read through these patches a bit but it's really unclear what the
> > > point of them is. I think they need better commit messages, or better
> > > comments, or both.
> >
> > Thanks for taking a look. Sorry about the lack of good commentary,
> > which I have tried to address in the attached updated version. I
> > extracted one more part as preparatory from the earlier 0003 patch, so
> > there are 4 patches now.
> >
> > Also as discussed with Daniel, I have changed the patches so that they
> > can be applied on plain HEAD instead of having to first apply the
> > patches at [1]. Without runtime pruning for UPDATE/DELETE proposed in
> > [1], optimizing ResultRelInfo creation by itself does not improve the
> > performance/scalability by that much, but the benefit of lazily
> > creating ResultRelInfos seems clear so I think maybe it's okay to
> > pursue this independently.
>
> Per cfbot's automatic patch tester, there were some issues in the 0004 patch:
>
> nodeModifyTable.c: In function ‘ExecModifyTable’:
> 1529nodeModifyTable.c:2484:24: error: ‘junkfilter’ may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> 1530 junkfilter->jf_junkAttNo,
> 1531 ^
> 1532nodeModifyTable.c:2309:14: note: ‘junkfilter’ was declared here
> 1533 JunkFilter *junkfilter;
> 1534 ^
> 1535cc1: all warnings being treated as errors
> 1536<builtin>: recipe for target 'nodeModifyTable.o' failed
> 1537make[3]: *** [nodeModifyTable.o] Error 1
>
> Fixed in the attached updated version

Needed a rebase due to f481d28232. Attached updated patches.

--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
v5-0004-Initialize-result-relation-information-lazily.patch application/octet-stream 58.9 KB
v5-0001-Revise-how-FDWs-obtain-result-relation-informatio.patch application/octet-stream 12.0 KB
v5-0002-Don-t-make-root-ResultRelInfo-for-insert-queries.patch application/octet-stream 7.4 KB
v5-0003-Revise-child-to-root-tuple-conversion-map-managem.patch application/octet-stream 20.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2020-09-14 04:48:55 Re: Print logical WAL message content
Previous Message Amit Kapila 2020-09-14 03:18:32 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions