On Wed, Dec 21, 2011 at 1:14 PM, Kevin Grittner <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
