Re: Avoiding second heap scan in VACUUM

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Avoiding second heap scan in VACUUM
Дата
Msg-id 1212039937.4489.727.camel@ebony.site
обсуждение исходный текст
Ответ на Re: Avoiding second heap scan in VACUUM  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Список pgsql-hackers
On Thu, 2008-05-29 at 09:57 +0530, Pavan Deolasee wrote:
> On Thu, May 29, 2008 at 2:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >
> >
> > I'm not happy that the VACUUM waits. It might wait a very long time and
> > cause worse overall performance than the impact of the second scan.
> >
> 
> Lets not get too paranoid about the wait. It's a minor detail in the
> whole theory. I would suggest that the benefit of avoiding second scan
> would be huge. Remember, its just not a scan, it also dirties those
> blocks again, forcing them write to disk. Also, if you really have a
> situation where vacuum needs to wait for very long, then you are
> already in trouble. The long running transactions would prevent
> vacuuming many tuples.
> 
> I think we can easily tweak the "wait" so that it doesn't wait
> indefinitely. If the "wait" times out, vacuum can still proceed, but
> it can mark the DEAD line pointers as DEAD_RECLAIMED. It would then
> have a choice of making a second pass and reclaiming the DEAD line
> pointers (like it does today).

Which is exactly what I suggested. Don't wait, just check.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: BUG #4204: COPY to table with FK has memory leak
Следующее
От: "Mike"
Дата:
Сообщение: Re: intercepting WAL writes