Excerpts from Robert Haas's message of mié may 25 12:27:38 -0400 2011:
> On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
> <pavan.deolasee@gmail.com> wrote:
> > I think if are reclaiming LP_DEAD line pointers only while
> > defragmenting the page, we can always reclaim the space for the LSN,
> > irrespective of where we store it. So may be we should decide
> > depending on what would matter for on-disk compatibility and whatever
> > requires least invasive changes. I don't know what is that yet.
>
> If we store the LSN at the beginning (page header) or end (special
> space) of the page, then we'll have to adjust the location of the data
> which follows it or precedes it if and when we want to reclaim the
> space it occupies. But if we store it in the hole in the middle
> somewhere (probably by reducing the size of the hole, not by actually
> referencing the area between pd_lower and pd_upper) then no tuples or
> item pointers have to move around when we want to reclaim the space.
> That way, we need only an exclusive lock (not a cleanup lock), and we
> don't need to memmove() anything.
You can store anything in the "hole" in the data area (currently we only
store tuple data), but then you'd have to store the offset to where you
stored it in some fixed location, and make sure you adjust pd_upper/lower
so that the next tuple does not overwrite it. You'd still need space
in either page header or special space. I don't see how you'd store
anything in the hole without it being in a fixed place, where it would
eventually be hit by either the line pointer array or tuple data.
As far as the general idea of this thread goes, I remember thinking
about exactly this topic a couple of months ago -- I didn't get this far
though, so thanks for fleshing out some details and getting the ball
rolling.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
