| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Added schema level support for publication. |
| Date: | 2021-06-16 11:29:45 |
| Message-ID: | CAA4eK1+9LYBseEFZo-3j+V8_RUndSvg3js_8YzYcuXL2Fdo-4w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jan 9, 2021 at 8:08 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> And, with this feature, since there can be many huge tables inside a
> schema, the initial table sync phase of the replication can take a
> while.
>
> Say a user has created a publication for a schema with hundreds of
> tables in it, at some point later, can he stop replicating a single or
> some tables from that schema?
>
Isn't this applies to FOR ALL TABLES syntax as well where the user
might want to exclude one or a few tables? I am not sure if it is a
good idea to deal with this as part of this patch.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | torikoshia | 2021-06-16 11:36:08 | Re: RFC: Logging plan of the running query |
| Previous Message | Matthias van de Meent | 2021-06-16 10:59:33 | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |