RE: Conflict detection for update_deleted in logical replication - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Conflict detection for update_deleted in logical replication
Date
Msg-id OSCPR01MB149660DD40A9D7C18E2E11C97F548A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Conflict detection for update_deleted in logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: Conflict detection for update_deleted in logical replication
List pgsql-hackers
Dear hackers,

> As per the above observations, it is less of a regression of this
> feature but more of a lack of parallel apply or some kind of pre-fetch
> for apply, as is recently proposed [1]. I feel there are use cases, as
> explained above, for which this feature would work without any
> downside, but due to a lack of some sort of parallel apply, we may not
> be able to use it without any downside for cases where the contention
> is only on a smaller set of tables. We have not tried, but may in
> cases where contention is on a smaller set of tables, if users
> distribute workload among different pub-sub pairs by using row
> filters, there also, we may also see less regression. We can try that
> as well.

I verified row filter idea by benchmark and this was the valid approach.
Please see the below report.

Highlights
=======
- No regression was observed when publisher changes were processed by multiple
  apply workers on the subscriber.

Used source
=========
pgHead commit 62a17a92833 + v47 patch set

Machine details
===========
Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz CPU(s) :88 cores, - 503 GiB RAM

Setup
====
 - Publisher and Subscriber nodes are created with configurations:
    autovacuum = false
    shared_buffers = '30GB'
    -- Also, worker and logical replication related parameters were increased
       as needed (see attached scripts for details).

Workload
======
 - The publisher has 4 pgbench tables: pgbench_pub_accounts, pgbench_pub_tellers,
   pgbench_pub_branches, and pgbench_pub_history
 - Also the publisher has 15 publications, say pub_[0..14]. Each publications could
   publish tuples which PK % 15 was same as their suffic
 - Ran pgbench with 15 clients for the *both side*.
 - On subscriber, there were 15 subscribers which subscribed one of the publication
 - On subscriber, the default pgbench workload is also run.
 - The duration was 5 minutes, and the measurement was repeated 3 times.

Test Scenarios & Results:
Publisher:
 - pgHead : Median TPS = 12201.92205
 - pgHead + patch : Median TPS = 12368.58001
(TPS reduced ~1.5%)

Subscriber:
 - pgHead : Median TPS = 11264.78483
 - pgHead + patch : Median TPS = 11471.8107
(TPS reduced ~1.8%)

Observation:
 - No performance regression was observed on either the publisher or subscriber
   with the patch applied.

Detailed Results Table
======================
Publisher:
#run    head        patched
1    12201.92205    12368.58001
2    12263.03531    12410.21465
3    12171.24214    12330.47522
median    12201.92205    12368.58001

Subscriber:
#run    head        patched
1    11383.51717    11471.8107
2    11264.78483    11422.47011
3    11146.6676    11518.8403
median    11264.78483    11471.8107

Best regards,
Hayato Kuroda
FUJITSU LIMITED

pgsql-hackers by date:

Previous
From: Nitin Motiani
Date:
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Conflict detection for update_deleted in logical replication