On Tue, 2012-06-12 at 13:31 -0400, Tom Lane wrote:
> 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?".
[waves hands wildly]
We could create a different HeapTupleSatisfiesMVCC routine that ignores
hint bits, and select that at the time the scan is started. That would
at least avoid affecting existing code paths.
> 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?
Hmm... but that still leaves PD_ALL_VISIBLE, which will also cause a
rewrite of the data. Under OLTP, we can assume that PD_ALL_VISIBLE is
much more rare than HEAP_XMIN_COMMITTED; but for bulk loads, setting
HEAP_XMIN_COMMITTED doesn't help us much without PD_ALL_VISIBLE.
> 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.
That may be reasonable, but it's much more dangerous than just breaking
MVCC (which to me implies isolation rules) -- pre-freezing would break
atomicity if you have any aborts. And I can't think of very many cases
where losing atomicity is reasonable (although I'm sure there are some).
Regards,Jeff Davis