Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

Поиск
Список
Период
Сортировка
От Ajin Cherian
Тема Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding
Дата
Msg-id CAFPTHDYPy0aVgSOe+4GwAzOpKecAKF9jdOMx=yb8jC06ExndXw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding  (Peter Smith <smithpb2250@gmail.com>)
Ответы Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding
Список pgsql-hackers
Hello,

I ran a series of tests using both streaming and non-streaming logical
replication modes with the patch. In non-streaming mode, the patch
showed a significant performance improvement — up to +68% in the best
case, with a -6% regression in the worst case.

In contrast, results in streaming mode were more modest. With the
default logical_decoding_work_mem of 64MB, I observed a +11.6%
improvement at best and a -6.7% degradation at worst. Increasing the
work memory provided some incremental improvements:

At 128MB: +14.43% (best), -0.65% (worst)

At 256MB: +12.55% (best), -0.03% (worst)

At 512MB: +16.98% (best), -2.48% (worst)

It's worth noting that streaming mode is enabled by default in logical
decoding, and as such, it's likely the mode most users and
applications are operating in. Non-streaming mode is typically only
used in more specialized setups or older deployments. Given this, the
broader benefit of the patch - especially considering its complexity,
may depend on how widely non-streaming mode is used in practice.

I'm sharing these findings in case others are interested in evaluating
the patch further. I believe the worst-case performance degradation
can be reduced with better code optimization. Feedback is welcome if
people believe it’s worthwhile to continue development based on these
results.

regards,
Ajin Cherian
Fujitsu Australia

Вложения

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