Re: Finalizing logical replication limitations as well as potentialfeatures
От
Alvaro Herrera
Тема
Re: Finalizing logical replication limitations as well as potentialfeatures
Дата
Msg-id
20180104212658.6tsk7wz7ffc43ka6@alvherre.pgsql
Ответ на
Список
Дерево обсуждения
Finalizing logical replication limitations as well as potentialfeatures "Joshua D. Drake" <jd@commandprompt.com>
Re: Finalizing logical replication limitations as well as potential features Craig Ringer <craig@2ndquadrant.com>
Re: Finalizing logical replication limitations as well as potentialfeatures "Joshua D. Drake" <jd@commandprompt.com>
Re: Finalizing logical replication limitations as well as potentialfeatures Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: Finalizing logical replication limitations as well as potentialfeatures "Joshua D. Drake" <jd@commandprompt.com>
Re: Finalizing logical replication limitations as well as potentialfeatures Alvaro Hernandez <aht@ongres.com>
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
В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата: