MIME-Version: 1.0
References: <705469.1678409199@sss.pgh.pa.us> <CA+hUKG+qm1xKt4peyu=3oyhzDpZ=pfPqAuk8W1fowb6Uae4+Eg@mail.gmail.com>
 <709425.1678411315@sss.pgh.pa.us> <CA+hUKGLd-U=cyVhbgoNxmPzHDqKiydGW8Knkcsv4=tWrM5KkoQ@mail.gmail.com>
 <CA+hUKGKBHSzx02SrDMSZvXRE52CR58jp8d5Z80_CKEMaaxJ8Sg@mail.gmail.com>
 <CA+hUKGKmGm6nT2_d=_MeqJe81tkNgzy_suXQc=GFdHuQt+XecA@mail.gmail.com>
 <1020590.1678488594@sss.pgh.pa.us> <CA+hUKGL6Lx0sS5DY8Acf_EzRKKyGtYZS2TYJDu7-FTn-hoZkDg@mail.gmail.com>
 <20230313231008.GB428842@nathanxps13> <CA+hUKGL=OkAsHBS_TH3v3SRCi3AZd9r2+8PpJ4DR=P9xvnhF5Q@mail.gmail.com>
 <20230314185428.GA431737@nathanxps13>
In-Reply-To: <20230314185428.GA431737@nathanxps13>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Wed, 15 Mar 2023 17:59:35 +1300
Message-ID: <CA+hUKGJcOmr1H55DxxvyiNu1qByUTY_A=5sBb7Y7SFfWTgRdRw@mail.gmail.com>
Subject: Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Melanie Plageman <melanieplageman@gmail.com>, 
	Pg Hackers <pgsql-hackers@postgresql.org>, Stephen Frost <sfrost@snowman.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BhUKGJcOmr1H55DxxvyiNu1qByUTY_A%3D5sBb7Y7SFfWTgRdRw%40mail.gmail.com>
Precedence: bulk

On Wed, Mar 15, 2023 at 7:54=E2=80=AFAM Nathan Bossart <nathandbossart@gmai=
l.com> wrote:
> Here is roughly what I had in mind:
>
>         NOTE: Although the delay is specified in microseconds, older Unix=
en and
>         Windows use periodic kernel ticks to wake up, which might increas=
e the
>         delay time significantly.  We've observed delay increases as larg=
e as
>         20 milliseconds on supported platforms.

Sold.  And pushed.

I couldn't let that 20ms !=3D 1s/100 problem go, despite my claim that I
would, and now I see:  NetBSD does have 10ms resolution, so everyone
can relax, arithmetic still works.  It's just that it always or often
adds on one extra tick, for some strange reason.  So you can measure
20ms, 30ms, ... but never as low as 10ms.  *Shrug*.  Your description
covered that nicely.

https://marc.info/?l=3Dnetbsd-current-users&m=3D144832117108168&w=3D2

> > (The word "interrupt" is a bit overloaded, which doesn't help with
> > this discussion.)
>
> Yeah, I think it would be clearer if "interrupt" was disambiguated.

OK, I rewrote it to avoid that terminology.

On small detail, after reading Tom's 2019 proposal to do this[1]: He
mentioned SUSv2's ENOSYS error.  I see that SUSv3 (POSIX.1-2001)
dropped that.  Systems that don't have the "timers" option simply
shouldn't define the function, but we already require the "timers"
option for clock_gettime().  And more practically, I know that all our
target systems have it and it works.

Pushed.

[1] https://www.postgresql.org/message-id/4902.1552349020@sss.pgh.pa.us