From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, ashwinstar(at)gmail(dot)com |
Subject: | Re: A micro-optimisation for ProcSendSignal() |
Date: | 2021-12-16 03:00:41 |
Message-ID: | CA+hUKGJo9rEyzvwJ=Jw1LncS4QH4zEyMnLfNqXinAjBrEXQ_JQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 3, 2021 at 2:56 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2021-08-03 13:44:58 +1200, Thomas Munro wrote:
> > In the case of buffer pin waits, we switch to storing the pgprocno of
> > the waiter. In the case of SERIALIZABLE READ ONLY DEFERRABLE waits, we
> > derive the pgprocno from the vxid (though that's not yet as efficient as
> > it could be).
>
> That's kind of an understatement :)
I abandoned the vxid part for now and went back to v3. If/when
BackendId is replaced with or becomes synonymous with pgprocno, we can
make this change and drop the pgprocno member from SERIALIZABLEXACT.
> > + SetLatch(&ProcGlobal->allProcs[pgprocno].procLatch);
> I think some validation of the pgprocno here would be a good idea. I'm worried
> that something could cause e.g. INVALID_PGPROCNO to be passed in, and suddenly
> we're modifying random memory. That could end up being a pretty hard bug to
> catch, because we might not even notice that the right latch isn't set...
Added.
> > /* Accessor for PGPROC given a pgprocno. */
> > #define GetPGProcByNumber(n) (&ProcGlobal->allProcs[(n)])
> > +/* Accessor for pgprocno given a pointer to PGPROC. */
> > +#define GetPGProcNumber(proc) ((proc) - ProcGlobal->allProcs)
>
> I'm not sure this is a good idea. There's no really cheap way for the compiler
> to compute this, because sizeof(PGPROC) isn't a power of two. Given that
> PGPROC is ~880 bytes, I don't see all that much gain in getting rid of
> ->pgprocno.
Yeah, that would need some examination; 0002 patch abandoned for now.
Pushed.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2021-12-16 03:03:11 | Re: COPY IN/BOTH vs. extended query mode |
Previous Message | kuroda.hayato@fujitsu.com | 2021-12-16 02:53:44 | RE: Allow escape in application_name |