From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 9.3: load path to mitigate load penalty for checksums |
Date: | 2012-06-12 21:50:11 |
Message-ID: | 1339537811.12295.38.camel@sussancws0025 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-06-12 21:53:04 | Re: 9.3: load path to mitigate load penalty for checksums |
Previous Message | Tom Lane | 2012-06-12 21:48:58 | Re: Ability to listen on two unix sockets |