Re: Finalizing logical replication limitations as well as potentialfeatures - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Finalizing logical replication limitations as well as potentialfeatures
Date
Msg-id 20180104212658.6tsk7wz7ffc43ka6@alvherre.pgsql
Whole thread Raw
In response to Re: Finalizing logical replication limitations as well as potentialfeatures  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Finalizing logical replication limitations as well as potentialfeatures
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] UPDATE of partition key