Re: TRUNCATE on foreign table
От | Kohei KaiGai |
---|---|
Тема | Re: TRUNCATE on foreign table |
Дата | |
Msg-id | CAOP8fzYnWtxtaFoeyF2fqKB1Pf_AA5RkoZhLtdeHUSDBpdFPTQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TRUNCATE on foreign table (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: TRUNCATE on foreign table
|
Список | 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 по дате отправления: