Re: Lock problem with autovacuum truncating heap
От | Simon Riggs |
---|---|
Тема | Re: Lock problem with autovacuum truncating heap |
Дата | |
Msg-id | AANLkTi=xu0XuqQ49u7=Q7KVe3EeZ1FqNuoDccp4Srcvc@mail.gmail.com обсуждение исходный текст |
Ответ на | Lock problem with autovacuum truncating heap (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: Lock problem with autovacuum truncating heap
Re: Lock problem with autovacuum truncating heap |
Список | pgsql-hackers |
On Sat, Mar 26, 2011 at 2:30 PM, Jan Wieck <JanWieck@yahoo.com> wrote: > My current idea for a fix is to modify lazy_truncate_heap(). It does acquire > and release the exclusive lock, so it should be possible to do this in > smaller chunks, releasing and reacquiring the lock so that client > transactions can get their work done as well. Agreed, presumably with vacuum delay in there as well? > At the same time I would > change count_nondeletable_pages() so that it uses a forward scan direction > (if that leads to a speedup). Do we need that? Linux readahead works in both directions doesn't it? Guess it wouldn't hurt too much. BTW does it read the blocks at that point using a buffer strategy? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: