Re: TRUNCATE on foreign table

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Kohei KaiGai <kaigai(at)heterodb(dot)com>, Kazutaka Onishi <onishi(at)heterodb(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Subject: Re: TRUNCATE on foreign table
Date: 2021-04-22 06:36:25
Message-ID: 45bf0b95-b8e8-b1ee-015e-0cb4cf732def@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021/04/22 9:39, Bharath Rupireddy wrote:
> One comment on truncate_foreign_table_docs_v1.patch:
> 1) I think it is "to be truncated"
> + <literal>rels</literal> is a list of <structname>Relation</structname>
> + data structures for each foreign table to truncated.

Fixed. Thanks!

> How about a slightly changed phrasing like below?
> + <literal>rels</literal> is a list of <structname>Relation</structname>
> + data structures of foreign tables to truncate.
Either works at least for me. If you think that this phrasing is
more precise or better, I'm ok with that and will update the patch again.

> Other than above, the patch LGTM.
>
>>> 3) How about adding an extra para(after below para in
>>> postgres_fdw.sgml) on WHY we don't push "ONLY" to foreign tables while
>>> truncating? We could add to the same para for other options if at all
>>> we don't choose to push them.
>>> <command>DELETE</command>, or <command>TRUNCATE</command>.
>>> (Of course, the remote user you have specified in your user mapping must
>>> have privileges to do these things.)
>>
>> I agree to document the behavior that ONLY option is always ignored
>> for foreign tables. But I'm not sure if we can document WHY.
>> Because I could not find the past discussion about why ONLY option is
>> ignored on SELECT, etc... Maybe it's enough to document the behavior?
>
> +1 to specify in the documentation about ONLY option is always
> ignored.

Added.

> But can we specify the WHY part within deparseTruncateSql, it
> will be there for developer reference? I feel it's better if this
> change goes with truncate_foreign_table_dont_pass_only_clause_v2.patch

I added this information into fdwhandler.sgml because the developers
usually read fdwhandler.sgml.

>>> 4) Isn't it better to mention the "ONLY" option is not pushed to remote
>>> -- truncate with ONLY clause
>>> TRUNCATE ONLY tru_ftable_parent;
>>>
>>> TRUNCATE ONLY tru_ftable; -- truncate both parent and child
>>> SELECT count(*) FROM tru_ftable; -- 0

I added the comment.

Could you review the attached patches?

Regards,

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

Attachment Content-Type Size
truncate_foreign_table_docs_v2.patch text/plain 4.3 KB
truncate_foreign_table_dont_pass_only_clause_v3.patch text/plain 17.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tsunakawa.takay@fujitsu.com 2021-04-22 06:40:19 RE: [bug?] Missed parallel safety checks, and wrong parallel safety
Previous Message Dilip Kumar 2021-04-22 06:06:24 Re: PageGetItemIdCareful - should we MAXALIGN sizeof(BTPageOpaqueData)?