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

From Euler Taveira
Subject Re: row filtering for logical replication
Date
Msg-id 4dbad191-9b40-4bb6-8940-d18f2e93c3ce@www.fastmail.com
Whole thread Raw
In response to Re: row filtering for logical replication  (David Steele <david@pgmasters.net>)
Responses Re: row filtering for logical replication  (japin <japinli@hotmail.com>)
List pgsql-hackers
On Mon, Mar 16, 2020, at 10:58 AM, David Steele wrote:
Please submit to a future CF when a new patch is available.
Hi,

This is another version of the row filter patch. Patch summary:

0001: refactor to remove dead code
0002: grammar refactor for row filter
0003: core code, documentation, and tests
0004: psql code
0005: pg_dump support
0006: debug messages (only for test purposes)
0007: measure row filter overhead (only for test purposes)

From the previous version I incorporated Amit's suggestions [1], improve documentation and tests. I refactored to code to make it simple to read (break the row filter code into functions). This new version covers the new parameter publish_via_partition_root that was introduced (cf 83fd4532a7).

Regarding function prohibition, I wouldn't like to open a can of worms (see previous discussions in this thread). Simple expressions covers most of the use cases that I worked with until now. This prohibition can be removed in another patch after some careful analysis.

I did some limited tests and didn't observe some excessive CPU usage while testing this patch tough I agree with Andres that retain some expression context into a cache would certainly speed up this piece of code. I measured the row filter overhead in my i7 (see 0007)  and got:

mean:           92.49 us
stddev:         32.63 us
median:         83.45 us
min-max:        [11.13 .. 2731.55] us
percentile(95): 117.76 us



--
Euler Taveira

Attachment

pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: new heapcheck contrib module
Next
From: Bharath Rupireddy
Date:
Subject: Re: Printing backtrace of postgres processes