On Tue, Jun 12, 2012 at 01:31:05PM -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > I don't think it's going to solve the problem in general, but TBH I > > don't think Jeff's proposal is, either. I mean, ignoring > > xmin-committed, xmax-committed, and all-visible bits is going to come > > with a pretty steep performance penalty all of its own. I don't doubt > > that you can construct situations in which it's better than incurring > > the I/O associated with setting those bits after the fact, but I also > > don't doubt that the reverse is true. Furthermore, any system that > > involves sometimes ignoring those things is going to add cost in > > extremely hot code paths even when the user doesn't elect to take > > advantage of the new feature. > > Yeah; the notion of adding cycles to the visibility-check code paths, > which would add cost even for users who have no use at all for this > feature, is close to being a deal-breaker for me. I would rather see > us designing this around the idea of "what can we do without adding > any new complexity in visibility checks?". > > At least for MVCC cases (hence, user tables only), it seems like we > could pre-set XMIN_COMMITTED hint bits if there were a way to be sure > that the XID in question would be seen as still running in the followup > snapshot check that every MVCC visibility test must make anyway. The > hard part of that seems to be post-crash behavior, but maybe it'd be > acceptable to incur crash-recovery-time cost to run around and unset > such bits?
Well, truncating tables that were empty on the load would certainly be a easy to do --- not sure if that helps us, though. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
