Re: pgsql: Compute XID horizon for page level index vacuum on primary. - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: pgsql: Compute XID horizon for page level index vacuum on primary.
Date
Msg-id CAH2-WznV8OWt3zQqjCYtYEU7MZ0aCFeWwqoZMDcpHUbpdWzDhQ@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Compute XID horizon for page level index vacuum on primary.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgsql: Compute XID horizon for page level index vacuum on primary.
List 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 by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Progress reporting for pg_verify_checksums
Next
From: Tomas Vondra
Date:
Subject: Re: Enable data checksums by default