| From: | Kazutaka Onishi <onishi(at)heterodb(dot)com> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kohei KaiGai <kaigai(at)heterodb(dot)com> |
| Subject: | Re: TRUNCATE on foreign table |
| Date: | 2021-02-09 14:15:03 |
| Message-ID: | CAJuF6cNVJC5+C2ci0FCgJBpSX8NZF+eaMTbcboDRtTPyagUttA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> IIUC, "truncatable" would be set to "false" for relations which do not
> have physical storage e.g. views but will be true for regular tables.
"truncatable" option is just for the foreign table and it's not related
with whether it's on a physical storage or not.
"postgres_fdw" already has "updatable" option to make the table read-only.
However, "updatable" is for DML, and it's not suitable for TRUNCATE.
Therefore new options "truncatable" was added.
Please refer to this message for details.
https://www.postgresql.org/message-id/20200128040346.GC1552%40paquier.xyz
> DELETE is very different from TRUNCATE. Application may want to DELETE
> based on a join with a local table and hence it can not be executed on
> a foreign server. That's not true with TRUNCATE.
Yeah, As you say, Applications doesn't need TRUNCATE.
We're focusing for analytical use, namely operating huge data.
TRUNCATE can erase rows faster than DELETE.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2021-02-09 14:17:04 | ERROR: invalid spinlock number: 0 |
| Previous Message | Peter Eisentraut | 2021-02-09 14:06:20 | Routine usage information schema tables |