Re: bghinter process - Mailing list pgsql-hackers

From Robert Haas
Subject Re: bghinter process
Date
Msg-id CA+TgmoZ3S0=U4RL1TAH1ELtJE1y-PzNXu4gZ=mTOfumRU3x59w@mail.gmail.com
Whole thread Raw
In response to bghinter process  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: bghinter process  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Wed, Dec 21, 2011 at 1:14 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Would it make sense, as suggested by Álvaro in the "CLOG contention"
> thread, to have a background process to set hint bits on tuples in
> dirty pages?  Processing could be loosely based around the
> background writer techniques in terms of sweeping through the cache,
> but it would only look at dirty pages (destined to be written
> anyway) and I think we might want to further limit it to looking at
> tuples with an xmin or xmax value which precede the global xmin
> value and doesn't yet have a hint.  It wouldn't do any writing; it
> would just check visibility and set hint bits.

Maybe.  But I think we'd need to see some test results showing that it
helps.  I mean, the nice thing about our current system is that we
don't set hint bits on tuples unless we otherwise have some need to
look at them.  Something like this COULD end up chewing up CPU time
and memory bandwidth without actually improving performance.  On a
high-velocity system we could dirty the same buffers multiple times in
the course of a second, so a background process that scans through the
buffer pool say, once per minute would effectively be standing still.

Now, that's not to say there aren't case where it would help.  I just
don't know exactly what they are.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: CLOG contention
Next
From: Simon Riggs
Date:
Subject: Re: sorting table columns