Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented
Дата
Msg-id CAKFQuwa0HTkNpRaUCcM_x3snyRRseQpCR8K-4JXf6suyCnJ_NQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented  (yigong hu <yigongh@gmail.com>)
Список pgsql-docs
Дерево обсуждения
On Tue, May 12, 2020 at 4:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.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.


В списке pgsql-docs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented
Следующее
От: yigong hu
Дата:
Сообщение: Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented