Re: row filtering for logical replication - Mailing list pgsql-hackers

From Greg Nancarrow
Subject Re: row filtering for logical replication
Date
Msg-id CAJcOf-eG9nQoYMdz5asBm5_JuKdQV+i7pv5PCxUqGU_K887x4w@mail.gmail.com
Whole thread Raw
In response to Re: row filtering for logical replication  (Ajin Cherian <itsajin@gmail.com>)
Responses Re: row filtering for logical replication  (Ajin Cherian <itsajin@gmail.com>)
List pgsql-hackers
On Wed, Oct 13, 2021 at 10:00 PM Ajin Cherian <itsajin@gmail.com> wrote:
>
> I have made the change to use the virtual slot for expression
> evaluation and avoided tuple deformation.
>

I started looking at the v32-0006 patch and have some initial comments.
Shouldn't old_slot, new_slot and tmp_new_slot be cached in the
RelationSyncEntry, similar to scantuple?
Currently, these slots are always getting newly allocated each call to
pgoutput_row_filter_update() - and also, seemingly never deallocated.
We previously found that allocating slots each time for each row
filtered (over 1000s of rows) had a huge performance overhead.
As an example, scantuple was originally newly allocated each row
filtered, and to filter 1,000,000 rows in a test case it was taking 40
seconds. Caching the allocation in RelationSyncEntry reduced it down
to about 5 seconds.

Regards,
Greg Nancarrow
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Shinya Kato
Date:
Subject: Re: [PATCH] Added TRANSFORM FOR for COMMENT tab completion
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()