Re: Single pass vacuum - take 2
От | Pavan Deolasee |
---|---|
Тема | Re: Single pass vacuum - take 2 |
Дата | |
Msg-id | CABOikdPFO7U5rrEkk7z84kxkFuZ3DGRkQj4m=qmSuLfuH_jNEQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Single pass vacuum - take 2 (Jim Nasby <jim@nasby.net>) |
Ответы |
Re: Single pass vacuum - take 2
|
Список | pgsql-hackers |
On Tue, Aug 23, 2011 at 2:47 AM, Jim Nasby <jim@nasby.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 vacuumfinds 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
В списке pgsql-hackers по дате отправления: