Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken
Date
Msg-id CA+hUKGKBHSzx02SrDMSZvXRE52CR58jp8d5Z80_CKEMaaxJ8Sg@mail.gmail.com
Whole thread Raw
In response to Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Fri, Mar 10, 2023 at 2:45 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> I'll go and see about usec latch waits.  More soon.

Here are some experimental patches along those lines.  Seems good
locally, but I saw a random failure I don't understand on CI so
apparently I need to find a bug; at least this gives an idea of how
this might look.  Unfortunately, the new interface on Linux turned out
to be newer that I first realised: Linux 5.11+ (so RHEL 9, Debian
12/Bookworm, Ubuntu 21.04/Hirsute Hippo), so unless we're OK with it
taking a couple more years to be more widely used, we'll need some
fallback code.  Perhaps something like 0004, which also shows the sort
of thing that we might consider back-patching to 14 and 15 (next
revision I'll move that up the front and put it in back-patchable
form).  It's not exactly beautiful; maybe sharing code with recovery's
lazy PM-exit detection could help.  Of course, the new μs-based wait
API could be used wherever we do timestamp-based waiting, for no
particular reason other than that it is the resolution of our
timestamps, so there is no need to bother rounding; I doubt anyone
would notice or care much about that, but it's vote in favour of μs
rather than the other obvious contender ns, which modern underlying
kernel primitives are using.

Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Rework LogicalOutputPluginWriterUpdateProgress
Next
From: Amit Kapila
Date:
Subject: Re: Rework LogicalOutputPluginWriterUpdateProgress