Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented

Thank you all for your fast response. I agree that back patching the
default change in general cases should be probably discussed in the hacker
mailing list to establish good practice. However, as a user, I would
typically just refer to the documentation of the specific version v11 in
this case instead of the latest v12. If I follow the v11 doc, I would not
be aware of the performance caveat. Since v11 is still a relatively recent
release and my testing demonstrates the same significant perf difference
exists in v11, I think it might be worth adding the note in the doc or wiki
to let the people of older versions know that the default value is changing
for catching up modern times.

On Wed, May 13, 2020 at 8:17 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Tue, May 12, 2020 at 4:59 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
>> > To be clear, because my cursory reading of the thread that was linked
>> from
>> > the commit suggested that this specific situation was more "lets catch
>> up
>> > to modern times", my position isn't that such documentation changes
>> should
>> > be done as a rule, I am suggesting that we give a yes/no decision on
>> this
>> > specific change (in advance of bike-shedding the wording). IMO neither
>> a
>> > blanket rule allowing or prohibiting such a change to the documentation
>> > makes sense given the rarity of the event.
>>
>> Sure. My point was just that changing the back-branch documentation would
>> require doing additional testing to verify that the proposed value is
>> an improvement in those branches.
>>
>>
> Yeah, details of any testing during v12 didn't make it into the thread,
> the main conclusion that did was:
>
> """
> However, the current settings are predicated on the assumption that
> you can't get the kernel to give you a sleep of less than circa 10ms.
> That assumption is way outdated, I believe; poking around on systems
> I have here, the minimum delay time using pg_usleep(1) seems to be
> generally less than 100us, and frequently less than 10us, on anything
> released in the last decade.
> """
>
> Hence assuming this was more of a "modernization". v12 has been out for a
> year (yeah, not a super long time, I know) and I'm not recalling any
> complaints about the new default. I don't have a feel, though, for what
> informal or other measurements that all you hackers do to get a feel for
> how safe and useful the change from 20ms to 2ms was.
>
> David's original post:
>
> """
> I've had to do quite a bit of performance investigation work this year
> and it seems that I only too often discover that the same problem is
> repeating itself...
> """
>
> I'd be inclined to assume many of those investigations were not on v12
> which lends itself to at least wanting to give admins of older versions a
> heads-up in the documentation. There seems to be consensus that this is a
> win - and people have a couple of months now to demonstrate that it isn't
> on older versions. (IOW, I'm not going to prove it one way or another but
> everything that went into having this committed in v12 leads me to at least
> tell people of older versions we changed things in v12 for reasons - even
> if we cover our rear ends and say we simply didn't test older versions and
> mileage may vary).
>
> David J.
>
>
>