> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@postgresql.org] On Behalf Of Merlin Moncure > Sent: Wednesday, November 07, 2012 5:26 AM > To: PostgreSQL-development > Cc: Atri Sharma > Subject: [HACKERS] WIP patch for hint bit i/o mitigation > > Following the sig is a first cut at a patch (written by Atri) that > attempts to mitigate hint bit i/o penalty when many pages worth of > tuples are sequentially written out with the same transaction id. > There have been other attempts to deal with this problem that fit > niche cases (especially those that create the table in the same > transaction as the one inserting) that work but don't really solve the > problem generally. > > I previously attacked this problem ([1], [2]) and came up with a patch > that cached hint bits inside tqual.c. The patch was pulled for a few > reasons: > > 1) a lot of complexity without proper justification > 2) sketchy cache replacement algorithm > 3) I manged to misspell 'committed' just about everywhere > 4) invalidation? > > Issues 1-3 could have been worked out but #4 was making me think the > problem was a nonstarter, or at least, 'too much too soon'. The tuple > visibility routines are in a very tight code path and having to deal > with various things in the backend that could cause the xid to become > stale were making me nervous. A smaller, simpler patch might be the > ticket.
About invalidation, I think the cached xid can become invalid due to xid wraparound. So for that one way could be to invalidate it through Vacuum. Though I am not sure what all other things can make cached id as invalid, but I think once we can think what other ways can make cached id invalid, then we can see if there is a solution to address them. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
