Reducing WaitEventSet syscall churn

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Reducing WaitEventSet syscall churn
Date: 2020-01-21 00:45:12
Message-ID: CA+hUKGJAC4Oqao=qforhNey20J8CiG2R=oBPqvfR0vOJrFysGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Here are some patches to get rid of frequent system calls.

0001 changes all qualifying WaitLatch() calls to use a new function
WaitMyLatch() that reuses a common WaitEventSet. That's for callers
that only want to wait for their own latch or an optional timeout,
with automatic exit-on-postmaster-death.

0002 changes condition_variable.c to use WaitMyLatch(), instead of its
own local thing like that. Perhaps this makes up for the use of the
extra fd consumed by 0001.

0003 changes pgstat.c to use its own local reusable WaitEventSet.

To see what I'm talking about, try tracing a whole cluster with eg
strace/truss/dtruss -f postgres -D pgdata. This applies to Linux
systems, or BSD/macOS systems with the nearby kqueue patch applied.
On systems that fall back to poll(), there aren't any setup/teardown
syscalls.

Attachment Content-Type Size
0001-Add-WaitMyLatch-to-replace-many-WaitLatch-calls.patch application/octet-stream 13.8 KB
0002-Use-WaitMyLatch-for-condition-variables.patch application/octet-stream 2.3 KB
0003-Introduce-a-reusable-WaitEventSet-for-the-stats-coll.patch application/octet-stream 2.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-21 00:46:52 Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Previous Message Kyotaro Horiguchi 2020-01-21 00:39:40 Re: Physical replication slot advance is not persistent