Delay the variable initialization in get_rel_sync_entry
Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
From: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-12-22T13:11:38Z
Lists: pgsql-hackers
Attachments
- 0001-Delay-the-variable-initialization-in-get_rel_sync_en.patch (application/octet-stream) patch 0001
Hi,
When reviewing some logical replication patches. I noticed that in
function get_rel_sync_entry() we always invoke get_rel_relispartition()
and get_rel_relkind() at the beginning which could cause unnecessary
cache access.
---
get_rel_sync_entry(PGOutputData *data, Oid relid)
{
RelationSyncEntry *entry;
bool am_partition = get_rel_relispartition(relid);
char relkind = get_rel_relkind(relid);
---
The extra cost could sometimes be noticeable because get_rel_sync_entry is a
hot function which is executed for each change. And the 'am_partition' and
'relkind' are necessary only when we need to rebuild the RelationSyncEntry.
Here is the perf result for the case when inserted large amounts of data into a
un-published table in which case the cost is noticeable.
--12.83%--pgoutput_change
|--11.84%--get_rel_sync_entry
|--4.76%--get_rel_relispartition
|--4.70%--get_rel_relkind
So, I think it would be better if we do the initialization only when
RelationSyncEntry in invalid.
Attach a small patch which delay the initialization.
Thoughts ?
Best regards,
Hou zj
Commits
-
Reduce relcache access in WAL sender streaming logical changes
- 3f8062bcf7f9 13.6 landed
- 5ddfebded41f 14.2 landed
- 6ce16088bfed 15.0 landed