On 10.05.2011 17:47, Robert Haas wrote:
On Tue, May 10, 2011 at 9:59 AM, Merlin Moncure<mmonc...@gmail.com> wrote:
no, that wasn't my intent at all, except in the sense of wondering if
a crash-safe visibility map provides a route of displacing a lot of
hint bit i/o and by extension, making alternative approaches of doing
that, including mine, a lot less useful. that's a good thing.
Sadly, I don't think it's going to have that effect. The
page-is-all-visible bits seem to offer a significant performance
benefit over the xmin-committed hint bits; but the benefit of
xmin-committed all by itself is too much to ignore. The advantages of
the xmin-committed hint bit (as opposed to the all-visible page-level
bit) are:
(1) Setting the xmin-committed hint bit is a much more light-weight
operation than setting the all-visible page-level bit. It can by done
on-the-fly by any backend, rather than only by VACUUM, and need not be
XLOG'd.
(2) If there are long-running transactions on the system,
xmin-committed can be set much sooner than all-visible - the
transaction need only commit. All-visible can't be set until
overlapping transactions have ended.
(3) xmin-committed is useful on standby servers, whereas all-visible
is ignored there. (Note that neither this patch nor index-only scans
changes anything about that: it's existing behavior, necessitated by
different xmin horizons.)
(4) xmin-committed flag attached directly to the tuple provides some
robustness in case of corruption, due to bad hw. Without the flag, a
single bit flip in the clog could in the worst case render all of your
bulk-loaded data invisible and vacuumable. Of course, corruption will
always eat your data to some extent, but the hint bits provide some
robustness. Hint bits are close to the data itself, not in another file
like the clog, which can come handy at disaster recovery.
A flag in the heap page header isn't too different from a per-tuple hint
bit from that point of view, it's still in the same page as the data
itself. A bit in the clog or visibility map is not.
Not sure how much performance we're willing to sacrifice for that, but
it's something to keep in mind.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
