Re: Placing hints in line pointers

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Placing hints in line pointers
Date: 2013-06-10 02:43:58
Message-ID: 1370832238.7746.11.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2013-06-10 05:00:44 pg_filedump 9.3: checksums (and a few other fixes)
Previous Message Joe Conway 2013-06-10 00:34:22 Re: pg_dump with postgis extension dumps rules separately