On Mon, Nov 7, 2011 at 9:12 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> SetHintBits() can't set HEAP_XMIN_COMMITTED or HEAP_XMAX_COMMITTED >> hints until the commit record has been durably flushed to disk. It >> turns out that can cause a major performance regression on systems >> with many CPU cores. > > It seems to me that you've jumped to proposing solutions before you know > where the problem actually is --- or at least, if you do know where the > problem is, you didn't explain it. Is the cost in repeating clog > lookups, or in testing to determine whether it's safe to set the bit > yet, or is it contention associated with one or the other of those?
In the current code, if you get to the IsValid check and fail to set the bit, you've essentially done all the work for no reason. I tested this pretty well a few months back, and (recalling from memory), the IsValid check is maybe 25% of the entire cost when you fail through the hint bit -- this is why I organized the cache to only store the bit if the xid was known good -- then you get to skip the check in the known good case and immediately set the bit (w/o marking dirty) and move on. As noted above, the cache I was playing with was a win from performance point of view, but would require another bit to address Robert's proposed case, and should really be prepared against alternative solutions (like marking the bit in the bgwriter) before being seriously considered. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers