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 |
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 |