| 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: | Whole Thread | Raw Message | 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 |