From: | David Christensen <david(at)endpoint(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Add `truncate` option to subscription commands |
Date: | 2020-10-10 12:16:47 |
Message-ID: | CBBA3387-8B66-40FE-8452-F1BB7543DD92@endpoint.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Oct 10, 2020, at 12:14 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sat, Oct 10, 2020 at 12:24 AM David Christensen <david(at)endpoint(dot)com> wrote:
>>
>> -hackers,
>>
>> Enclosed find a patch to add a “truncate” option to subscription commands.
>>
>> When adding new tables to a subscription (either via `CREATE SUBSCRIPTION` or `REFRESH PUBLICATION`), tables on the target which are being newly subscribed will be truncated before the data copy step. This saves explicit coordination of a manual `TRUNCATE` on the target tables and allows the results of the initial data sync to be the same as on the publisher at the time of sync.
>>
>
> So IIUC, this will either truncate all the tables for a particular
> subscription or none?
Correct, when creating or altering the subscription all newly added tables would be left alone (current behavior) or truncated (new functionality from the patch).
> Is it possible that the user wants some of
> those tables to be truncated which made me think what exactly made you
> propose this feature? Basically, is it from user complaint, or is it
> some optimization that you think will be helpful to users?
This comes from my own experience with setting up/modifying subscriptions with adding many multiple additional tables, some of which had data in the subscribing node. I would have found this feature very helpful.
Thanks,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-10-10 12:23:53 | Re: BUG #15858: could not stat file - over 4GB |
Previous Message | Amit Kapila | 2020-10-10 11:55:42 | Re: Parallel INSERT (INTO ... SELECT ...) |