Forgot to attach the patch.
On Thu, Sep 7, 2023 at 1:22 PM Ashutosh Bapat
<ashutosh.bapat....@gmail.com> wrote:
>
> Hi Junwang,
> We leave a line blank after variable declaration as in the attached patch.
>
> Otherwise the patch looks good to me.
>
> The function modified by the patch is only used by extension
> pgrowlocks. Given that the function will be invoked as many times as
> the number of locked rows in the relation, the patch may show some
> improvement and thus be more compelling. One way to measure
> performance is to create a table with millions of rows, SELECT all
> rows with FOR SHARE/UPDATE clause. Then run pgrowlock() on that
> relation. This will invoke the given function a million times. That
> way we might be able to catch some miniscule improvement per row.
>
> If the performance is measurable, we can mark the CF entry as ready
> for committer.
>
> --
> Best Wishes,
> Ashutosh Bapat
>
> On Thu, Aug 10, 2023 at 1:48 PM Junwang Zhao <zhjw...@gmail.com> wrote:
> >
> > On Thu, Aug 10, 2023 at 4:11 PM Ashutosh Bapat
> > <ashutosh.bapat....@gmail.com> wrote:
> > >
> > > Please add this to commitfest so that it's not forgotten.
> > >
> >
> > Added [1], thanks
> >
> > [1]: https://commitfest.postgresql.org/44/4495/
> >
> > > On Wed, Aug 9, 2023 at 8:37 PM Junwang Zhao <zhjw...@gmail.com> wrote:
> > > >
> > > > On Wed, Aug 9, 2023 at 10:46 PM Ashutosh Bapat
> > > > <ashutosh.bapat....@gmail.com> wrote:
> > > > >
> > > > > On Wed, Aug 9, 2023 at 9:30 AM Junwang Zhao <zhjw...@gmail.com> wrote:
> > > > > >
> > > > > > In function `BackendXidGetPid`, when looping every proc's
> > > > > > TransactionId, there is no need to access its PGPROC since there
> > > > > > is shared memory access: `arrayP->pgprocnos[index]`.
> > > > > >
> > > > > > Though the compiler can optimize this kind of inefficiency, I
> > > > > > believe we should ship with better code.
> > > > > >
> > > > >
> > > > > Looks good to me. However, I would just move the variable declaration
> > > > > with their assignments inside the if () rather than combing the
> > > > > expressions. It more readable that way.
> > > >
> > > > yeah, make sense, also checked elsewhere using the original style,
> > > > attachment file
> > > > keep that style, thanks ;)
> > > >
> > > > >
> > > > > --
> > > > > Best Wishes,
> > > > > Ashutosh Bapat
> > > >
> > > >
> > > >
> > > > --
> > > > Regards
> > > > Junwang Zhao
> > >
> > >
> > >
> > > --
> > > Best Wishes,
> > > Ashutosh Bapat
> >
> >
> >
> > --
> > Regards
> > Junwang Zhao
--
Best Wishes,
Ashutosh Bapat
From 7ad91841dda0f49e7bcc44809b58230ed67d80f7 Mon Sep 17 00:00:00 2001
From: Zhao Junwang <zhjw...@gmail.com>
Date: Wed, 9 Aug 2023 11:43:21 +0800
Subject: [PATCH] only access allProcs when xid matches
In function `BackendXidGetPid`, when looping every proc's
TransactionId, there is no need to access its PGPROC since there
is shared memory access: `arrayP->pgprocnos[index]`.
Though the compiler can optimize this kind of inefficiency, I
believe we should ship with better code.
Signed-off-by: Zhao Junwang <zhjw...@gmail.com>
---
src/backend/storage/ipc/procarray.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index bfbf7f903f..d93475b2bd 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -3174,11 +3174,11 @@ BackendXidGetPid(TransactionId xid)
for (index = 0; index < arrayP->numProcs; index++)
{
- int pgprocno = arrayP->pgprocnos[index];
- PGPROC *proc = &allProcs[pgprocno];
-
if (other_xids[index] == xid)
{
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
result = proc->pid;
break;
}
--
2.25.1
