Re: pgsql: Compute XID horizon for page level index vacuum on primary.

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: pgsql: Compute XID horizon for page level index vacuum on primary.
Дата
Msg-id CAH2-WznV8OWt3zQqjCYtYEU7MZ0aCFeWwqoZMDcpHUbpdWzDhQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgsql: Compute XID horizon for page level index vacuum on primary.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pgsql: Compute XID horizon for page level index vacuum on primary.  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
On Sat, Mar 30, 2019 at 8:44 AM Robert Haas <robertmhaas@gmail.com> wrote:
> Overall I'm inclined to think that we're making the same mistake here
> that we did with work_mem, namely, assuming that you can control a
> bunch of different prefetching behaviors with a single GUC and things
> will be OK.  Let's just create a new GUC for this and default it to 10
> or something and go home.

I agree. If you invent a new GUC, then everybody notices, and it
usually has to be justified quite rigorously. There is a strong
incentive to use an existing GUC, if only because the problem that
this creates is harder to measure than the supposed problem that it
avoids. This can perversely work against the goal of making the system
easy to use. Stretching the original definition of a GUC is bad.

I take issue with the general assumption that not adding a GUC at
least makes things easier for users. In reality, it depends entirely
on the situation at hand.

-- 
Peter Geoghegan



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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: Progress reporting for pg_verify_checksums
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Enable data checksums by default