Re: Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands
Date
Msg-id CALj2ACX5JKVsY-scb9cpud6qhe4ue6BTLkjRHfHc2JOedHx2DQ@mail.gmail.com
Whole thread Raw
In response to Re: Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
On Fri, Apr 9, 2021 at 9:23 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> On 2021/04/10 0:39, Amul Sul wrote:
> > On Fri, Apr 9, 2021 at 8:51 PM Bharath Rupireddy
> > <bharath.rupireddyforpostgres@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> While checking the ExecuteTruncate code for the FOREIGN TRUNCATE
> >> feature, I saw that we filter out the duplicate relations specified in
> >> the TRUNCATE command. But before skipping the duplicates, we are just
> >> opening the relation, then if it is present in the already seen
> >> relids, then closing it and continuing further.
> >>
> >> I think we can just have the duplicate checking before table_open so
> >> that in cases like TRUNCATE foo, foo, foo, foo; we could save costs of
> >> table_open and table_close. Attaching a small patch. Thoughts?
> >>
> >> This is just like what we already do for child tables, see following
> >> in ExecuteTruncate:
> >>              foreach(child, children)
> >>              {
> >>                  Oid            childrelid = lfirst_oid(child);
> >>
> >>                  if (list_member_oid(relids, childrelid))
> >>                      continue;
> >>
> >
> > Well yes, the patch looks pretty much reasonable to be.
>
> LGTM, too. I will commit this patch.
> Though that code exists even in older version, I'm not thinking
> to back-patch that because it's not a bug.

Thanks. +1 to not back-patch.

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Replication slot stats misgivings
Next
From: Tom Lane
Date:
Subject: Re: pgsql: autovacuum: handle analyze for partitioned tables