On Thu, Dec 23, 2021 at 12:54:41PM -0300, Euler Taveira wrote:
> On Wed, Dec 22, 2021, at 10:11 AM, houzj.fnst@fujitsu.com wrote:
>> 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
How does the perf balance change once you apply the patch? Do we have
anything else that stands out? Getting rid of this bottleneck is fine
by itself, but I am wondering if there are more things to worry about
or not.
> Good catch. WFM. Deferring variable initialization close to its first use is
> good practice.
Yeah, it is usually a good practice to have the declaration within
the code block that uses it rather than piling everything at the
beginning of the function. Being able to see that in profiles is
annoying, and the change is simple, so I'd like to backpatch it.
This is a period of vacations for a lot of people, so I'll wait until
the beginning-ish of January before doing anything.
--
Michael
