From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | A micro-optimisation for ProcSendSignal() |
Date: | 2021-03-11 11:31:44 |
Message-ID: | CA+hUKGLYRyDaneEwz5Uya_OgFLMx5BgJfkQSD=q9HmwsfRRb-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
ProcSendSignal(pid) searches the ProcArray for the given pid and then
sets that backend's procLatch. It has only two users: UnpinBuffer()
and ReleasePredicateLocks(). In both cases, we could just as easily
have recorded the pgprocno instead, avoiding the locking and the
searching. We'd also be able to drop some special book-keeping for
the startup process, whose pid can't be found via the ProcArray.
A related idea, saving space in BufferDesc but having to do slightly
more expensive work, would be for UnpinBuffer() to reuse the new
condition variable instead of ProcSendSignal().
Attachment | Content-Type | Size |
---|---|---|
0001-Optimize-ProcSendSignal.patch | text/x-patch | 9.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2021-03-11 11:36:17 | Re: pg_amcheck contrib application |
Previous Message | mickiewicz | 2021-03-11 11:29:49 | first add newly loaded plugin to the list then invoke _PG_init |