Re: Proposal: Another attempt at vacuum improvements - Mailing list pgsql-hackers

On Wed, May 25, 2011 at 12:48 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> 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.

You only need one bit of space in the page header, to indicate whether
the LSN is present or not.  And we have unused bit space there.

> 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.

The point is that it doesn't matter.  Suppose we put it just after the
line pointer array.  Any time we're thinking about extending the line
pointer array, we already have an exclusive lock on the buffer.  And
if we already have a exclusive lock on the buffer, then we can reclaim
the dead line pointers and now we no longer need the saved LSN, so
writing over it is perfectly fine.

OK, I lied: if we have an exclusive buffer lock, but the last vacuum
either failed, or is still in progress, then the LSN might not be old
enough for us to reclaim the dead line pointers yet.  So ideally we'd
like to hold onto it.  We can do that by either (a) moving the LSN out
another 6 bytes, if there's enough room; or (b) deciding not to put
the new tuple on this page, after all.  There's no situation in which
we absolutely HAVE to get another tuple onto this particular page.  We
can just decide that the effective size of a page that contains dead
line pointers is effectively 8 bytes less.  The alternative is to eat
up 8 bytes of space on ALL pages, whether they contain dead line
pointers or not.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company