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
Ответ на
Re: Quick idea for reducing VACUUM contention (Alvaro Herrera)
Список
Дерево обсуждения
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 по дате отправления