Re: heap vacuum & cleanup locks

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: heap vacuum & cleanup locks
Дата
Msg-id BANLkTikbLZb3NyUHJHpx4kbYdaoR9+2m0Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: heap vacuum & cleanup locks  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: heap vacuum & cleanup locks  (Simon Riggs <simon@2ndQuadrant.com>)
Re: heap vacuum & cleanup locks  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> But I think you've hit the important point here. The problem is not
> whether VACUUM waits for the pin, its that the pins can be held for
> extended periods.

Yes

> It makes more sense to try to limit pin hold times than it does to
> come up with pin avoidance techniques.

Well it's super-exclusive-vacuum-lock avoidance techniques. Why
shouldn't it make more sense to try to reduce the frequency and impact
of the single-purpose outlier in a non-critical-path instead of
burdening every other data reader with extra overhead?

I think Robert's plan is exactly right though I would phrase it
differently. We should get the exclusive lock, freeze/kill any xids
and line pointers, then if the pin-count is 1 do the compaction.

I'm really wishing we had more bits in the vm. It looks like we could use:- contains not-all-visible tuples- contains
not-frozenxids- in need of compaction
 

I'm sure we could find a use for one more page-level vm bit too.



-- 
greg


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: reducing the overhead of frequent table locks - now, with WIP patch
Следующее
От: Greg Smith
Дата:
Сообщение: Re: patch for new feature: Buffer Cache Hibernation