Обсуждение: bghinter process
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. -Kevin
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
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
On Wed, Dec 21, 2011 at 1:59 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > But, well, tuples that are succesfully hinted need no more hint bits. Not only do they need no more hinting, they also allow the next client-serving process that hits it avoid the clog lookup to determine the hint. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.