Re: Single pass vacuum - take 2

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Single pass vacuum - take 2
Date: 2011-08-30 10:38:44
Message-ID: CABOikdPFO7U5rrEkk7z84kxkFuZ3DGRkQj4m=qmSuLfuH_jNEQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 23, 2011 at 2:47 AM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> On Aug 22, 2011, at 1:22 AM, Pavan Deolasee wrote:
>> Hi All,
>>
>> Here is a revised patch based on our earlier discussion. I implemented
>> Robert's idea of tracking the vacuum generation number in the line
>> pointer itself. For LP_DEAD line pointers, the lp_off/lp_len is unused
>> (and always set to 0 for heap tuples). We use those 30 bits to store
>> the generation number of the vacuum which would have potentially
>> removed the corresponding index pointers, if the vacuum finished
>> successfully. The pg_class information is used to know the status of
>> the vacuum, whether it failed or succeeded. 30-bit numbers are large
>> enough that we can ignore any wrap-around related issues. With this
>
> +        * Note: We don't worry about the wrap-around issues here since it would
> +        * take a 1 Billion vacuums on the same relation for the vacuum generation
> +        * to wrap-around. That would take ages to happen and even if it happens,
> +        * the chances that we might have dead-vacuumed line pointers still
> +        * stamped with the old (failed) vacuum are infinitely small since some
> +        * other vacuum cycle would have taken care of them.
>
> It would be good if some comment explained how we're safe in the case of an aborted vacuum. I'm guessing that when vacuum finds any line pointers that don't match the last successful vacuum exactly it will go and re-examine them from scratch?
>

Yeah. If we don't know the status of the vacuum that collected the
line pointer and marked it vacuum-dead, the next vacuum will pick it
up again and stamp it with its own generation number.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-08-30 10:41:00 Re: WIP: Fast GiST index build
Previous Message Alexander Korotkov 2011-08-30 10:38:10 Re: WIP: Fast GiST index build