Horton

Re: TRUNCATE on foreign table

Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>

View thread View on postgr.es
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: Zhihong Yu <zyu@yugabyte.com>
Cc: Kazutaka Onishi <onishi@heterodb.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Kohei KaiGai <kaigai@heterodb.com>, Amit Langote <amitlangote09@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: 2021-04-04T04:07:46Z
Lists: pgsql-hackers 
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.

> 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.

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

Commits

  1. doc: Review for "Allow TRUNCATE command to truncate foreign tables".

  2. Don't pass "ONLY" options specified in TRUNCATE to foreign data wrapper.

  3. Support tab-complete for TRUNCATE on foreign tables.

  4. Allow TRUNCATE command to truncate foreign tables.

  5. Add support for asynchronous execution.