Re: [HACKERS] Slow synchronous logical replication

On 12 October 2017 at 16:09, Konstantin Knizhnik wrote: > > Is the CREATE TABLE and INSERT done in the same transaction? > > No. Table was create in separate transaction. > Moreover the same effect will take place if table is create before start of > replication. >

Re: [HACKERS] Slow synchronous logical replication

On 12.10.2017 04:23, Craig Ringer wrote: On 12 October 2017 at 00:57, Konstantin Knizhnik wrote: The reason of such behavior is obvious: wal sender has to decode huge transaction generate by insert although it has no relation to this publication. It does. Though

Re: [HACKERS] Slow synchronous logical replication

On 12 October 2017 at 00:57, Konstantin Knizhnik wrote: > The reason of such behavior is obvious: wal sender has to decode huge > transaction generate by insert although it has no relation to this > publication. It does. Though I wouldn't expect anywhere near the kind

Re: [HACKERS] Slow synchronous logical replication

On 11.10.2017 10:07, Craig Ringer wrote: On 9 October 2017 at 15:37, Konstantin Knizhnik wrote: Thank you for explanations. On 08.10.2017 16:00, Craig Ringer wrote: I think it'd be helpful if you provided reproduction instructions, test programs, etc, making it

Re: [HACKERS] Slow synchronous logical replication

Hi, On 2017-10-09 10:37:01 +0300, Konstantin Knizhnik wrote: > So we have implement sharding - splitting data between several remote tables > using pg_pathman and postgres_fdw. > It means that insert or update of parent table cause insert or update of > some derived partitions which is forwarded

Re: [HACKERS] Slow synchronous logical replication

On 9 October 2017 at 15:37, Konstantin Knizhnik wrote: > Thank you for explanations. > > On 08.10.2017 16:00, Craig Ringer wrote: >> >> I think it'd be helpful if you provided reproduction instructions, >> test programs, etc, making it very clear when things are /

Re: [HACKERS] Slow synchronous logical replication

On Mon, Oct 9, 2017 at 4:37 PM, Konstantin Knizhnik wrote: > Thank you for explanations. > > On 08.10.2017 16:00, Craig Ringer wrote: >> >> I think it'd be helpful if you provided reproduction instructions, >> test programs, etc, making it very clear when things are /

Re: [HACKERS] Slow synchronous logical replication

Thank you for explanations. On 08.10.2017 16:00, Craig Ringer wrote: I think it'd be helpful if you provided reproduction instructions, test programs, etc, making it very clear when things are / aren't related to your changes. It will be not so easy to provide some reproducing scenario,

Re: [HACKERS] Slow synchronous logical replication

On 8 October 2017 at 03:58, Konstantin Knizhnik wrote: > The question was about logical replication mechanism in mainstream version > of Postgres. I think it'd be helpful if you provided reproduction instructions, test programs, etc, making it very clear when things

Re: [HACKERS] Slow synchronous logical replication

On 10/07/2017 10:42 PM, Andres Freund wrote: Hi, On 2017-10-07 22:39:09 +0300, konstantin knizhnik wrote: In our sharded cluster project we are trying to use logical relication for providing HA (maintaining redundant shard copies). Using asynchronous logical replication has not so much sense

Re: [HACKERS] Slow synchronous logical replication

Hi, On 2017-10-07 22:39:09 +0300, konstantin knizhnik wrote: > In our sharded cluster project we are trying to use logical relication for > providing HA (maintaining redundant shard copies). > Using asynchronous logical replication has not so much sense in context of > HA. This is why we try to

[HACKERS] Slow synchronous logical replication

In our sharded cluster project we are trying to use logical relication for providing HA (maintaining redundant shard copies). Using asynchronous logical replication has not so much sense in context of HA. This is why we try to use synchronous logical replication. Unfortunately it shows very bad