On Sat, 2013-06-01 at 15:45 +0100, Simon Riggs wrote:
> Doing this would have two purposes:
>
> * We wouldn't need to follow the pointer if the row is marked aborted.
> This would save a random memory access for that tuple
That's quite similar to LP_DEAD, right? You could potentially set this
new hint sooner, which may be an advantage.
> We wouldn't need to do a FPW when a hint changes, we would only need
> to take a copy of the ItemId array, which is much smaller. And it
> could be protected by its own checksum.
I like the direction of this idea.
I don't see exactly how you want to make this safe, though. During
replay, we can't just replace the ItemId array, because the other
contents on the page might be newer (e.g. some tuples may have been
cleaned out, leaving the item pointers pointing to the wrong place).
> (In addition, if we wanted, this could be used to extend block size to
> 64kB if we used 8-byte alignment for tuples)
I think that supporting 64KB blocks has merit.
Interesting observation about the extra bits available. That would be an
on-disk format change, so perhaps this is something to add to the list
of "waiting for a format change"?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
