Re: row filtering for logical replication

Поиск
Список
Период
Сортировка
От Peter Smith
Тема Re: row filtering for logical replication
Дата
Msg-id CAHut+PsE-EvynUUPL8oV7jqJU-Jvrdd8BbvJM-iLXe8_CxRmdw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: row filtering for logical replication  (Andres Freund <andres@anarazel.de>)
Ответы Re: row filtering for logical replication
Re: row filtering for logical replication
Список 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
>

I have gathered performance data for the workload case (a):

HEAD 46743.75
v74 no filters 46929.15
v74 allow 100% 46926.09
v74 allow 75% 40617.74
v74 allow 50% 35744.17
v74 allow 25% 29468.93
v74 allow 0% 22540.58

PSA.

This was tested using patch v74 and synchronous pub/sub. There are 1M
INSERTS for publications using differing amounts of row filtering (or
none).

Observations:
- There seems insignificant row-filter overheads (e.g. viz no filter
and 100% allowed versus HEAD).
- The elapsed time decreases linearly as there is less data getting replicated.

I will post the results for other workload kinds (b, c, d) when I have them.

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

Вложения

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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Proposal: More structured logging
Следующее
От: Yugo NAGATA
Дата:
Сообщение: Research and Interview on scale-out solutions in Japan