On Fri, Nov 16, 2012 at 8:58 AM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2012-11-16 08:43:12 -0600, Merlin Moncure wrote: >> On Thu, Nov 15, 2012 at 9:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> > Jeff Davis <pg...@j-davis.com> writes: >> >> It occurred to me recently that many of the hint bits aren't terribly >> >> important (at least it's not obvious to me). HEAP_XMIN_COMMITTED clearly >> >> has a purpose, and we'd expect it to be used many times following the >> >> initial CLOG lookup. >> > >> > Right. >> > >> >> But the other tuple hint bits seem to be there just for symmetry, >> >> because they shouldn't last long. If HEAP_XMIN_INVALID or >> >> HEAP_XMAX_COMMITTED is set, then it's (hopefully) going to be vacuumed >> >> soon, and gone completely. And if HEAP_XMAX_INVALID is set, then it >> >> should just be changed to InvalidTransactionId. >> > >> > Hm. It is not cheaper to change xmax to 0 than it is to set the hint >> > bit --- you still need a write, and there are also added locking and >> > atomicity worries --- so I'm not convinced by your argument there. >> > But you might be right that the expected number of wins from the other >> > two bits is a lot less. >> >> Is that true in a post checksum world though? Given that we are >> logging changes can we relax atomicity expectations? IIRC xmin/xmax >> are aligned, how come you can't just set InvalidTransactionId for >> INVALID and 'FrozenTransactionId' for COMMITTED? Why can't you do >> this now? > > Uhm. The latter doesn't really work if you have any transactions that > might not see that row or am I missing something?
nope. you're right. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
