On Tue, Jun 12, 2012 at 01:31:05PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
