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
Дата
Msg-id CAOxFffeQSGsjmbdFSdu-+m=DjrL3+BLpQNPZvZbA5aJqiTUhKQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-docs
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.g.johnston@gmail.com> wrote:
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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented
Следующее
От: Marina Polyakova
Дата:
Сообщение: Missing comma?