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
Re: heap vacuum & cleanup locks |
Список | 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 по дате отправления: