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

From Fujii Masao
Subject Re: Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands
Date
Msg-id 2513bd0c-663e-02fc-d1d8-104113843dbe@oss.nttdata.com
Whole thread Raw
In response to Re: Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers

On 2021/04/10 11:32, Bharath Rupireddy wrote:
> 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.

Pushed only to the master. Thanks!

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: PL/R regression on windows, but not linux with master.
Next
From: Tom Lane
Date:
Subject: Re: psql - add SHOW_ALL_RESULTS option