Re: Placing hints in line pointers - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Placing hints in line pointers
Date
Msg-id 1370832238.7746.11.camel@jdavis
Whole thread Raw
In response to Placing hints in line pointers  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Placing hints in line pointers  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
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





pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: pg_dump with postgis extension dumps rules separately
Next
From: Jeff Davis
Date:
Subject: pg_filedump 9.3: checksums (and a few other fixes)