On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
>> I'm confused. A major point of the approach I was proposing was to
>> avoid having to move tuples around.
>
> Well, I am not sure how you can always guarantee to make space
> available for the LSN without moving tuples , irrespective of where
> you store it. But probably its not important as we discussed below.
Well, if we just defragged the page, then we should be guaranteed that
pd_lower + 8 < pd_upper. No?
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
