Re: Track the amount of time waiting due to cost_delay

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Track the amount of time waiting due to cost_delay
Date: 2024-06-10 21:58:13
Message-ID: CA+TgmoY6nAVESkFj527-K2HLELt3JK+QrO37udzDp9KQqoTZrQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 10, 2024 at 11:36 AM Nathan Bossart
<nathandbossart(at)gmail(dot)com> wrote:
> Hm. Should we measure the actual time spent sleeping, or is a rough
> estimate good enough? I believe pg_usleep() might return early (e.g., if
> the process is signaled) or late, so this field could end up being
> inaccurate, although probably not by much. If we're okay with millisecond
> granularity, my first instinct is that what you've proposed is fine, but I
> figured I'd bring it up anyway.

I bet you could also sleep for longer than planned, throwing the
numbers off in the other direction.

I'm always suspicious of this sort of thing. I tend to find nothing
gives me the right answer unless I assume that the actual sleep times
are randomly and systematically different from the intended sleep
times but arbitrarily large amounts. I think we should at least do
some testing: if we measure both the intended sleep time and the
actual sleep time, how close are they? Does it change if the system is
under crushing load (which might elongate sleeps) or if we spam
SIGUSR1 against the vacuum process (which might shorten them)?

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John H 2024-06-10 22:51:05 Allow logical failover slots to wait on synchronous replication
Previous Message Jelte Fennema-Nio 2024-06-10 21:43:22 Re: RFC: adding pytest as a supported test framework