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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Compute XID horizon for page level index vacuum on primary.
Date: 2019-03-30 19:19:57
Message-ID: CAH2-WznV8OWt3zQqjCYtYEU7MZ0aCFeWwqoZMDcpHUbpdWzDhQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sat, Mar 30, 2019 at 8:44 AM Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Thomas Munro 2019-03-30 21:33:12 Re: pgsql: Compute XID horizon for page level index vacuum on primary.
Previous Message Tomas Vondra 2019-03-30 18:47:34 pgsql: Additional fixes of memory alignment in pg_mcv_list code

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-03-30 19:25:43 Re: Enable data checksums by default
Previous Message Fabien COELHO 2019-03-30 17:52:56 Re: Progress reporting for pg_verify_checksums