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
обсуждение исходный текст
Ответ на Re: Finalizing logical replication limitations as well as potentialfeatures  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: Finalizing logical replication limitations as well as potentialfeatures  ("Joshua D. Drake" <jd@commandprompt.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key