Re: A micro-optimisation for ProcSendSignal()
От | Thomas Munro |
---|---|
Тема | Re: A micro-optimisation for ProcSendSignal() |
Дата | |
Msg-id | CA+hUKGJo9rEyzvwJ=Jw1LncS4QH4zEyMnLfNqXinAjBrEXQ_JQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: A micro-optimisation for ProcSendSignal() (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Tue, Aug 3, 2021 at 2:56 PM Andres Freund <andres@anarazel.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.
В списке pgsql-hackers по дате отправления: