Re: Quick idea for reducing VACUUM contention

Поиск
Список
Период
Сортировка
Искать
От
Jim Nasby
Тема
Re: Quick idea for reducing VACUUM contention
Дата
Msg-id
C964C8DB-5A03-48F3-AC83-064D9E6B34D4@decibel.org
Ответ на
Список
Дерево обсуждения
Quick idea for reducing VACUUM contention "Simon Riggs" <simon@2ndquadrant.com>
Re: Quick idea for reducing VACUUM contention ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: Quick idea for reducing VACUUM contention Alvaro Herrera <alvherre@commandprompt.com>
Re: Quick idea for reducing VACUUM contention ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: Quick idea for reducing VACUUM contention Alvaro Herrera <alvherre@commandprompt.com>
Re: Quick idea for reducing VACUUM contention Decibel! <decibel@decibel.org>
Re: Quick idea for reducing VACUUM contention Alvaro Herrera <alvherre@commandprompt.com>
Re: Quick idea for reducing VACUUM contention Jim Nasby <decibel@decibel.org>
Re: Quick idea for reducing VACUUM contention Alvaro Herrera <alvherre@commandprompt.com>
Re: Quick idea for reducing VACUUM contention Decibel! <decibel@decibel.org>
On Jul 27, 2007, at 1:49 AM, Alvaro Herrera wrote:
> ITAGAKI Takahiro wrote:
>> "Simon Riggs"  wrote:
>>
>>> Read the heap blocks in sequence, but make a conditional lock for
>>> cleanup on each block. If we don't get it, sleep, then try again  
>>> when we
>>> wake up. If we fail the second time, just skip the block completely.
>
> It would be cool if we could do something like sweep a range of pages,
> initiate IO for those that are not in shared buffers, and while  
> that is
> running, lock and clean up the ones that are in shared buffers,  
> skipping
> those that are not lockable right away; when that's done, go back to
> those buffers that were gotten from I/O and clean those up.  And retry
> the locking for those that couldn't be locked the first time around,
> also conditionally.  And when that's all done, a third pass could get
> those blocks that weren't cleaned up in none of the previous passes  
> (and
> this time the lock would not be conditional).

Would that be substantially easier than just creating a bgreader?
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)



В списке pgsql-hackers по дате отправления
От: Jim Nasby
Дата:
Сообщение: Re: stats_block_level
От: Erik Jones
Дата:
Сообщение: Re: stats_block_level
FAQ