From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken |
Date: | 2023-03-09 22:02:51 |
Message-ID: | 620014.1678399371@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Fri, Mar 10, 2023 at 10:26 AM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
>> I think that 4753ef37e0ed undid the work caf626b2c did to support
>> sub-millisecond delays for vacuum and autovacuum.
> Given that some of the clunkier underlying kernel primitives have
> milliseconds in their interface, I don't think it would be possible to
> make a usec-based variant of WaitEventSetWait() that works everywhere.
> Could it possibly make sense to do something that accumulates the
> error, so if you're using 0.5 then every second vacuum_delay_point()
> waits for 1ms?
Yeah ... using float math there was cute, but it'd only get us so far.
The caf626b2c code would only work well on platforms that have
microsecond-based sleep primitives, so it was already not too portable.
Can we fix this by making VacuumCostBalance carry the extra fractional
delay, or would a separate variable be better?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2023-03-09 22:08:37 | Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken |
Previous Message | Tom Lane | 2023-03-09 21:50:11 | Re: Date-time extraneous fields with reserved keywords |