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

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Robert Haas <robertmhaas(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 21:33:12
Message-ID: CA+hUKG+Ks+dgCU018onG2_NM0rBajkQfrVmJKYei-f_y+z59eA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sun, Mar 31, 2019 at 8:20 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> 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.

I'm not sure I understand why this is any different from the bitmap
heapscan case though, or in fact why we are adding 10 in this case.
In both cases we will soon be reading the referenced buffers, and it
makes sense to queue up prefetch requests for the blocks if they
aren't already in shared buffers. In both cases, the number of
prefetch requests we want to send to the OS is somehow linked to the
amount of IO requests we think the OS can handle concurrently at once
(since that's one factor determining how fast it drains them), but
it's not necessarily the same as that number, AFAICS. It's useful to
queue some number of prefetch requests even if you have no IO
concurrency at all (a single old school spindle), just because the OS
will chew on that queue in the background while we're also doing
stuff, which is probably what that "+ 10" is expressing. But that
seems to apply to bitmap heapscan too, doesn't it?

--
Thomas Munro
https://enterprisedb.com

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2019-03-30 21:45:05 Re: pgsql: Compute XID horizon for page level index vacuum on primary.
Previous Message Peter Geoghegan 2019-03-30 19:19:57 Re: pgsql: Compute XID horizon for page level index vacuum on primary.

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-03-30 21:45:05 Re: pgsql: Compute XID horizon for page level index vacuum on primary.
Previous Message Daniel Gustafsson 2019-03-30 21:08:48 Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL