Excerpts from Robert Haas's message of mié dic 21 15:47:13 -0300 2011:
> 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.
The bad thing about that is you have client-connected processes doing
CLOG lookups to figure out the hint values, which adds latency to them.
I guess we're not concerned very much about the latency of this
bghinter -- the only thing it'd do is add some pressure to the clog
LRU; so maybe one thing to keep in mind is that bghinter should add its
clog pages near the tail of the LRU queue, not the head, so that it
doesn't evict pages that are being used by client-connected backends.
This bghinter could keep a cache of committed/aborted transactions of
its own, further reducing the need to look up clog pages.
> 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.
But, well, tuples that are succesfully hinted need no more hint bits.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support