| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Finalizing logical replication limitations as well as potential features |
| Date: | 2018-01-04 21:26:58 |
| Message-ID: | 20180104212658.6tsk7wz7ffc43ka6@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Joshua D. Drake wrote:
> We just queue/audit the changes as they happen and sync up the changes
> after the initial sync completes.
This already happens. There is an initial sync, and there's logical
decoding that queues any changes that exist "after" the sync's snapshot.
What you seem to want is to have multiple processes doing the initial
COPY in parallel -- each doing one fraction of the table. Of course,
they would have to use the same snapshot. That would make sense only
if the COPY itself is the bottleneck and not the network, or the I/O
speed of the origin server. This doesn't sound a common scenario to me.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2018-01-04 21:34:18 | Re: [HACKERS] UPDATE of partition key |
| Previous Message | Alexander Korotkov | 2018-01-04 21:25:52 | Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug |