Finalizing logical replication limitations as well as potentialfeatures

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Finalizing logical replication limitations as well as potentialfeatures
Дата
Msg-id c0bd70aa-7254-6217-1442-ec7bf144929c@commandprompt.com
обсуждение исходный текст
Ответы Re: Finalizing logical replication limitations as well as potential features  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
-Hackers,


As I continue to test Logical Replication and its native capabilities I 
have found the following:


It appears it is not possible to do this:

publisher->public.foo replicates to subscriber->private.foo

This one seems like a relatively simple fix (theoretically) and I think 
should be done. I can imagine dozens of scenarios where I want a source 
to replicate to a destination but within a different schema.

It also appears I can't do this:

publisher->public.foo replicates to subscriber->partitioned->public.foo

Here I was hoping that we could have multiple sources replicating into 
single partitioned table that would automatically segregate the database 
based on the partition key.

Lastly, I noted that a full sync of a replication set is performed by a 
COPY, this is fine for small sets but if we have a large data set that 
may take some time it may be a problem with overall performance and 
maintenance. We may want to see if we can do an initial sync 
incrementally (optional) via a cursor (?) and queue all changed rows 
until the sync completes?

Just some thoughts, I tried to ask on Slack as well as IRC but it 
doesn't appear many of the community are doing much with Logical Rep yet.


Thanks in advance,


JD


-- 
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc

PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
*****     Unless otherwise stated, opinions are my own.   *****



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pgsql: Get rid of copy_partition_key
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pgsql: Get rid of copy_partition_key