Re: Piggybacking vacuum I/O

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Piggybacking vacuum I/O
Дата
Msg-id 2e78013d0701230813i34b907bcha74bd52d2505b7af@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Piggybacking vacuum I/O  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On 1/23/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> Would it help to set the status of the XMIN/XMAX of tuples early enough such
> that the heap page is still in the buffer cache, but late enough such that
> the XMIN/XMAX transactions are finished ? How about doing it when the
> bgwriter is about to write the page to disk ?

No.  The bgwriter would then become subject to deadlocks because it
would be needing to read in clog pages before it could flush out
dirty pages.  In any case, if the table is in active use then some
passing backend has probably updated the bits already ...

Well, let me collect some evidence. If we figure out that there is indeed a
CLOG buffer thrash at VACUUM time, I am sure we would be able to solve
the problem one way or the other.
 
IMHO this case would be more applicable to the very large tables where the
UPDATEd rows are not accessed again for a long time. And hence the hint bits
might not have been updated.

Thanks,
Pavan




--

EnterpriseDB     http://www.enterprisedb.com

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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: 10 weeks to feature freeze (Pending Work)
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: "tupdesc reference is not owned by resource owner Portal" issue in 8.2 and -HEAD