On Wed, Dec 21, 2011 at 1:14 PM, Kevin Grittner
> 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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2011-12-21 18:53:20|
|Subject: Re: sorting table columns|
|Previous:||From: Robert Haas||Date: 2011-12-21 18:34:49|
|Subject: Re: CLOG contention|