From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
---|---|
To: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Delay the variable initialization in get_rel_sync_entry |
Date: | 2021-12-23 15:54:41 |
Message-ID: | 9bd1820b-1624-4112-93e2-e33f6e96dd81@www.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 22, 2021, at 10:11 AM, houzj(dot)fnst(at)fujitsu(dot)com wrote:
> 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
Good catch. WFM. Deferring variable initialization close to its first use is
good practice.
--
Euler Taveira
EDB https://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-12-23 16:13:36 | Re: Buildfarm support for older versions |
Previous Message | Bharath Rupireddy | 2021-12-23 15:46:02 | Re: correct the sizes of values and nulls arrays in pg_control_checkpoint |