On Wed, 8 Apr 2020 at 14:44, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Tue, Apr 7, 2020 at 5:17 PM Masahiko Sawada > <masahiko.saw...@2ndquadrant.com> wrote: > > > > On Tue, 7 Apr 2020 at 18:29, Masahiko Sawada > > <masahiko.saw...@2ndquadrant.com> wrote: > > > > > > On Tue, 7 Apr 2020 at 17:42, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > > > On Tue, Apr 7, 2020 at 1:30 PM Masahiko Sawada > > > > <masahiko.saw...@2ndquadrant.com> wrote: > > > > > > > > > > Buffer usage statistics seem correct. The small differences would be > > > > > catalog lookups Peter mentioned. > > > > > > > > > > > > > Agreed, but can you check which part of code does that lookup? I want > > > > to see if we can avoid that from buffer usage stats or at least write > > > > a comment about it, otherwise, we might have to face this question > > > > again and again. > > > > > > Okay, I'll check it. > > > > > > > I've checked the buffer usage differences when parallel btree index > > creation. > > > > TL;DR; > > > > During tuple sorting individual parallel workers read blocks of > > pg_amproc and pg_amproc_fam_proc_index to get the sort support > > function. The call flow is like: > > > > ParallelWorkerMain() > > _bt_parallel_scan_and_sort() > > tuplesort_begin_index_btree() > > PrepareSortSupportFromIndexRel() > > FinishSortSupportFunction() > > get_opfamily_proc() > > > > Thanks for the investigation. I don't see we can do anything special > about this. In an ideal world, this should be done once and not for > each worker but I guess it doesn't matter too much. I am not sure if > it is worth adding a comment for this, what do you think? >
I agree with you. If the differences were considerably large probably we would do something but I think we don't need to anything at this time. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
