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?
This doesn't do anything for pre-freezing of course, but I basically
don't see any way that we could pre-freeze without breaking MVCC
semantics anyhow. So there's still attraction in the idea of offering
users the choice of not sustaining MVCC behavior in exchange for cheaper
bulk loads.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
