Claudio Freire <klaussfre...@gmail.com> writes:
> On Sat, Oct 27, 2012 at 3:41 PM, Heikki Linnakangas
> <hlinnakan...@vmware.com> wrote:
>>> I think you're just moving the atomic-write problem from the data pages
>>> to wherever you keep these pointers.
>> If the pointers are stored as simple 4-byte integers, you probably could
>> assume that they're atomic, and won't be torn.
> That could backfire.
Yeah, the potential loss in resiliency is scary. Assume for the sake of
argument that we're storing these indirection pointers in 8K pages, 2000
or so to the page. If you get a read failure on a regular heap page,
you've lost 8K worth of data. If you get a read failure on an
indirection page, you've lost 16MB worth. (Though perhaps the pointers
could be reconstructed, given additional overhead data on each regular
heap page; but that wouldn't be very cheap.) Also, the write traffic
on a pointer page is 2000X as much as it is on an average heap page,
offering 2000X the opportunities for the disk hardware to drop a bit,
or for SSD storage to wear down, etc. (Perhaps it's not that bad for
typical access patterns, but then again perhaps it's worse, given the
already noted strict requirements for write ordering.) So it seems like
there'd be a rather nasty magnification of consequences for hardware
errors.
You've also got something like a 2000X concentration of access
contention for pointer pages compared to regular pages.
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
