Re: row filtering for logical replication - Mailing list pgsql-hackers

From Peter Smith
Subject Re: row filtering for logical replication
Date
Msg-id CAHut+PtTvYCU+h74DUtgFSyRmPJfS3rzz-LFOuHi_cSUEJ=gkQ@mail.gmail.com
Whole thread Raw
In response to Re: row filtering for logical replication  (Andres Freund <andres@anarazel.de>)
Responses Re: row filtering for logical replication
List pgsql-hackers
On Sat, Jan 29, 2022 at 11:31 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> Are there any recent performance evaluations of the overhead of row filters? I
> think it'd be good to get some numbers comparing:
>
> 1) $workload with master
> 2) $workload with patch, but no row filters
> 3) $workload with patch, row filter matching everything
> 4) $workload with patch, row filter matching few rows
>
> For workload I think it'd be worth testing:
> a) bulk COPY/INSERT into one table
> b) Many transactions doing small modifications to one table
> c) Many transactions targetting many different tables
> d) Interspersed DDL + small changes to a table
>

Here are performance data results for the workload case (c):

HEAD 105.75
v74 no filters 105.86
v74 allow 100% 104.94
v74 allow 75% 97.12
v74 allow 50% 78.92
v74 allow 25% 69.71
v74 allow 0% 59.70

This was tested using patch v74 and synchronous pub/sub.
There are 100K INSERTS/UPDATES over 5 tables (all published)
The PUBLICATIONS use differing amounts of row filtering (or none).

Observations:
- We see pretty much the same pattern as for workloads "a" and "b"
- There seems insignificant row-filter overheads (e.g. viz no filter
and 100% allowed versus HEAD).
- The elapsed time decreases as more % data is filtered out (i.e as
replication happens).

PSA workload "c" test files for details.

------
Kind Regards,
Peter Smith.
Fujitsu Australia.

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: do only critical work during single-user vacuum?
Next
From: Fabien COELHO
Date:
Subject: Re: Latest LLVM breaks our code again