Re: row filtering for logical replication
От | Peter Smith |
---|---|
Тема | Re: row filtering for logical replication |
Дата | |
Msg-id | CAHut+Pv6rEPg-nSRJq=MJDb6wRmhAM6k==hu6ihMaZ9EQVvMkw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: row filtering for logical replication (Peter Smith <smithpb2250@gmail.com>) |
Ответы |
Re: row filtering for logical replication
|
Список | pgsql-hackers |
On Tue, Feb 1, 2022 at 12:07 PM Peter Smith <smithpb2250@gmail.com> wrote: > > 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. > FYI - attached are the test steps I used in case anyone wants to try to reproduce these results. ------ Kind Regards, Peter Smith. Fujitsu Australia
Вложения
В списке pgsql-hackers по дате отправления: