Re: TRUNCATE on foreign table - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: TRUNCATE on foreign table
Date
Msg-id CAOP8fzYnWtxtaFoeyF2fqKB1Pf_AA5RkoZhLtdeHUSDBpdFPTQ@mail.gmail.com
Whole thread Raw
In response to Re: TRUNCATE on foreign table  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: TRUNCATE on foreign table  (Kazutaka Onishi <onishi@heterodb.com>)
List pgsql-hackers
2021年4月4日(日) 13:07 Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>:
>
> On Sat, Apr 3, 2021 at 8:31 PM Zhihong Yu <zyu@yugabyte.com> wrote:
> > w.r.t. Bharath's question on using hash table, I think the reason is that the search would be more efficient:
>
> Generally, sequential search would be slower if there are many entries
> in a list. Here, the use case is to store all the foreign table ids
> associated with each foreign server and I'm not sure how many foreign
> tables will be provided in a single truncate command that belong to
> different foreign servers. I strongly feel the count will be less and
> using a list would be easier than to have a hash table. Others may
> have better opinions.
>
https://www.postgresql.org/message-id/20200115081126.GK2243@paquier.xyz

It was originally implemented using a simple list, then modified according to
the comment by Michael.
I think it is just a matter of preference.

> > Should the hash table be released at the end of ExecuteTruncateGuts() ?
>
> If we go with a hash table and think that the frequency of "TRUNCATE"
> commands on foreign tables is heavy in a local session, then it does
> make sense to not destroy the hash, otherwise destroy the hash.
>
In most cases, TRUNCATE is not a command frequently executed.
So, exactly, it is just a matter of preference.

Best regards,
--
HeteroDB, Inc / The PG-Strom Project
KaiGai Kohei <kaigai@heterodb.com>



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unused variable found in AttrDefaultFetch
Next
From: Jaime Casanova
Date:
Subject: Re: Crash in BRIN minmax-multi indexes