RE: Plans for solving the VACUUM problem

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: Plans for solving the VACUUM problem
Дата
Msg-id 3705826352029646A3E91C53F7189E32016637@sectorbase2.sectorbase.com
обсуждение исходный текст
Ответ на Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Plans for solving the VACUUM problem  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Plans for solving the VACUUM problem  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
> > My point is that we'll need in dynamic cleanup anyway and UNDO is
> > what should be implemented for dynamic cleanup of aborted changes.
> 
> I do not yet understand why you want to handle aborts different than
> outdated tuples.

Maybe because of aborted tuples have shorter Time-To-Live.
And probability to find pages for them in buffer pool is higher.

> The ratio in a well tuned system should well favor outdated tuples.
> If someone ever adds "dirty read" it is also not the case that it
> is guaranteed, that nobody accesses the tuple you currently want
> to undo. So I really miss to see the big difference.

It will not be guaranteed anyway as soon as we start removing
tuples without exclusive access to relation.

And, I cannot say that I would implement UNDO because of
1. (cleanup) OR 2. (savepoints) OR 4. (pg_log management)
but because of ALL of 1., 2., 4.

Vadim


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Is stats update during COPY IN really a good idea?
Следующее
От: teg@redhat.com (Trond Eivind Glomsrød)
Дата:
Сообщение: Re: Using 7.1rc1 under RH 6.2