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
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 |
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 |