Re: row filtering for logical replication

Поиск
Список
Период
Сортировка
От Euler Taveira
Тема Re: row filtering for logical replication
Дата
Msg-id f4a77a2b-1555-4e79-bc38-f13d59a7ac8b@www.fastmail.com
обсуждение исходный текст
Ответ на Re: row filtering for logical replication  (Greg Nancarrow <gregn4422@gmail.com>)
Ответы Re: row filtering for logical replication
Список pgsql-hackers
On Wed, Jul 7, 2021, at 2:24 AM, Greg Nancarrow wrote:
I found that with the call to ExecInitExtraTupleSlot() in
pgoutput_row_filter(), then the performance of pgoutput_row_filter()
degrades considerably over the 100,000 invocations, and on my system
it took about 43 seconds to filter and send to the subscriber.
However, by caching the tuple table slot in RelationSyncEntry, this
duration can be dramatically reduced by 38+ seconds.
A further improvement can be made using this in combination with
Peter's plan cache (v16-0004).
I've attached a patch for this, which relies on the latest v16-0001
and v16-0004 patches posted by Peter Smith (noting that v16-0001 is
identical to your previously-posted 0001 patch).
Also attached is a graph (created by Peter Smith – thanks!) detailing
the performance improvement.
Greg, I like your suggestion and already integrate it (I replaced
ExecAllocTableSlot() with MakeSingleTupleTableSlot() because we don't need the
List). I'm still working on a new version to integrate all suggestions that you
and Peter did. I have a similar code to Peter's plan cache and I'm working on
merging both ideas together. I'm done for today but I'll continue tomorrow.


--
Euler Taveira

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

Предыдущее
От: Yugo NAGATA
Дата:
Сообщение: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
Следующее
От: Peter Smith
Дата:
Сообщение: parse_subscription_options - suggested improvements