From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-11-03 08:27:52 |
Message-ID: | CA+HiwqFafpkr8-m5HRWvStQ1esTX1q_Hu8MYB5twi3-tNa3nXQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 2, 2020 at 10:53 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Mon, Nov 2, 2020 at 10:19 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> > (/me reads patch further) I presume that's what you referred to in the
> > commit message:
> >
> > > Also, extend this lazy initialization approach to some of the
> > > individual fields of ResultRelInfo such that even for the result
> > > relations that are initialized, those fields are only initialized on
> > > first access. While no performance improvement is to be expected
> > > there, it can lead to a simpler initialization logic of the
> > > ResultRelInfo itself, because the conditions for whether a given
> > > field is needed or not tends to look confusing. One side-effect
> > > of this is that any "SubPlans" referenced in the expressions of
> > > those fields are also lazily initialized and hence changes the
> > > output of EXPLAIN (without ANALYZE) in some regression tests.
> >
> >
> > I'm now curious what the initialization logic would look like, if we
> > initialized those fields in ExecGetResultRelation(). At a quick glance
> > on the conditions on when those initializations are done in the patch
> > now, it would seem pretty straightforward. If the target list contains
> > any junk columns, initialize junk filter, and if
> > ModifyTable->returningLists is set, initialize RETURNING list. Maybe I'm
> > missing something.
>
> Yeah, it's not that complicated to initialize those things in
> ExecGetResultRelation(). In fact, ExecGetResultRelation() (or its
> subroutine ExecBuildResultRelation()) housed those initializations in
> the earlier versions of this patch, but I changed that after our
> discussion about being lazy about initializing as much stuff as we
> can. Maybe I should revert that?
Please check the attached if that looks better.
--
Amit Langote
EDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
v7-0001-Call-BeginDirectModify-from-ExecInitModifyTable.patch | application/octet-stream | 3.8 KB |
v7-0002-Initialize-result-relation-information-lazily.patch | application/octet-stream | 51.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2020-11-03 08:31:20 | Re: Online checksums verification in the backend |
Previous Message | Juan José Santamaría Flecha | 2020-11-03 08:12:30 | Re: Collation versioning |