Re: Idea for getting rid of VACUUM FREEZE on cold pages

Поиск
Список
Период
Сортировка
От Jesper Krogh
Тема Re: Idea for getting rid of VACUUM FREEZE on cold pages
Дата
Msg-id C4B54ABC-26C4-4416-AE30-B76EEF7E8C29@krogh.cc
обсуждение исходный текст
Ответ на Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On 27/05/2010, at 02.48, Robert Haas <robertmhaas@gmail.com> wrote:

> On Wed, May 26, 2010 at 8:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Josh Berkus <josh@agliodbs.com> writes:
>>> How does that get us out of reading and writing old pages, though?
>>
>> Yeah.  Neither PD_ALL_VISIBLE nor the visibility map are going to  
>> solve
>> your problem, because they cannot become set without having visited  
>> the
>> page.
>
> Well, maybe I'm confused here, but arranging things so that we NEVER
> have to visit the page after initially writing it seems like it's
> setting the bar almost impossibly high.   Consider a table that is
> regularly written but append-only.  Every time autovacuum kicks in,
> we'll go and remove any dead tuples and then mark the pages
> PD_ALL_VISIBLE and set the visibility map bits, which will cause
> subsequent vacuums to ignore the all-visible portions of the table...
> until anti-wraparound kicks in, at which point we'll vacuum the entire
> table and freeze everything.

Just a thought.  Wouldn't a All-visible bit also enable index only  
scans to some degree?

Jesper


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joshua Tolley
Дата:
Сообщение: Re: [PATCH] Add _PG_init to PL language handler documentation
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Synchronization levels in SR