On Tue, Mar 11, 2025 at 8:46 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
>
>
> On 2025/03/11 20:55, Ashutosh Bapat wrote:
> > Hi Fujii-san,
> >
> > It seems that this was forgotten somehow.
> >
> > The patch still applies.
> >
> > Examining c4d5cb71d229095a39fda1121a75ee40e6069a2a, it seems that this patch
> > could have been part of that commit as well. But may be it wasn't so apparent
> > that time. I think it's a good improvement.
>
> Thanks for reviewing the patch!
>
>
> > On Tue, Nov 19, 2024 at 10:14 PM Fujii Masao
> > <masao.fujii@oss.nttdata.com> wrote:
> >>
> >> The latest version of the patch is attached.
> >
> > @@ -2773,6 +2773,10 @@ FastPathTransferRelationLocks(LockMethod
> > lockMethodTable, const LOCKTAG *locktag
> > LWLock *partitionLock = LockHashPartitionLock(hashcode);
> > Oid relid = locktag->locktag_field2;
> > uint32 i;
> > + uint32 group;
> > +
> > + /* fast-path group the lock belongs to */
> > + group = FAST_PATH_REL_GROUP(relid);
> >
> > We could just combine variable declaration and initialization; similar
> > to partitionLock.
>
> I’ve updated the patch as suggested. Updated patch is attached.
>
Thanks.
>
> > The performance gain from this patch might be tiny and may not be
> > visible. Still, have you tried to measure the performance improvement?
>
> I haven’t measured the actual performance gain since the patch optimizes
> the logic in a clear and logical way. While we might see some improvement
> in artificial scenarios — like with a large max_connections and
> all backends slots having their databaseIds set, I’m not sure
> how meaningful that would be.
Fair enough. The code is more readable this way. That itself is an improvement.
I stared at c4d5cb71d229095a39fda1121a75ee40e6069a2a to see whether
there's any reason this was left aside at that time. I am convinced
that it was just missed. I think this patch is good to be committed.
--
Best Wishes,
Ashutosh Bapat
