From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>, 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-05-15 00:11:28 |
Message-ID: | 20190515001128.g6u5c2hia5ujtvsq@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Hi,
On 2019-05-15 12:01:07 +1200, Thomas Munro wrote:
> On Thu, May 2, 2019 at 5:10 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Wed, May 1, 2019 at 12:50 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > > Not strongly enough to argue about it very hard. The current behavior
> > > > is a little weird, but it's a long way from being the weirdest thing
> > > > we ship, and it appears that we have no tangible evidence that it
> > > > causes a problem in practice.
> > >
> > > I think there's nothing that fails to suck about a hardwired "+ 10".
> >
> > It avoids a performance regression without adding another GUC.
> >
> > That may not be enough reason to keep it like that, but it is one
> > thing that does fail to suck.
>
> This is listed as an open item to resolve for 12. IIUC the options on
> the table are:
>
> 1. Do nothing, and ship with effective_io_concurrency + 10.
> 2. Just use effective_io_concurrency without the hardwired boost.
> 3. Switch to a new GUC maintenance_io_concurrency (or some better name).
>
> The rationale for using a different number is that this backend is
> working on behalf of multiple sessions, so you might want to give it
> some more juice, much like maintenance_work_mem.
>
> I vote for option 3. I have no clue how to set it, but at least users
> have a fighting chance of experimenting and figuring it out that way.
> I volunteer to write the patch if we get a consensus.
I'd personally, unsurprisingly perhaps, go with 1 for v12. I think 3 is
also a good option - it's easy to imagine to later use it for for
VACUUM, ANALYZE and the like. I think 2 is a bad idea.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-05-15 15:53:13 | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |
Previous Message | Thomas Munro | 2019-05-15 00:01:07 | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2019-05-15 00:34:10 | Re: PostgreSQL 12: Feature Highlights |
Previous Message | Thomas Munro | 2019-05-15 00:01:07 | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |