On Friday, December 24, 2021 8:13 AM Michael Paquier <mich...@paquier.xyz> wrote: > > On Thu, Dec 23, 2021 at 12:54:41PM -0300, Euler Taveira wrote: > > On Wed, Dec 22, 2021, at 10:11 AM, houzj.f...@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.
Thanks for the response.
Here is the perf result of pgoutput_change after applying the patch.
I didn't notice something else that stand out.
|--2.99%--pgoutput_change
|--1.80%--get_rel_sync_entry
|--1.56%--hash_search
Also attach complete profiles.
> > 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.
+1
> This is a period of vacations for a lot of people, so I'll wait until
> the beginning-ish of January before doing anything.
Thanks, added it to CF.
https://commitfest.postgresql.org/36/3471/
Best regards,
Hou zj
<<attachment: perf.zip>>
