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 по дате отправления: