Re: Bug: Buffer cache is not scan resistant
От | Jim Nasby |
---|---|
Тема | Re: Bug: Buffer cache is not scan resistant |
Дата | |
Msg-id | AF45B115-9BF5-47F6-8C05-B2459EE84D4F@decibel.org обсуждение исходный текст |
Ответ на | Re: Bug: Buffer cache is not scan resistant (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mar 6, 2007, at 12:17 AM, Tom Lane wrote: > Jim Nasby <decibel@decibel.org> writes: >> An idea I've been thinking about would be to have the bgwriter or >> some other background process actually try and keep the free list >> populated, > > The bgwriter already tries to keep pages "just in front" of the clock > sweep pointer clean. True, but that still means that each backend has to run the clock- sweep. AFAICT that's something that backends will serialize on (due to BufFreelistLock), so it would be best to make StrategyGetBuffer as fast as possible. It certainly seems like grabbing a buffer off the free list is going to be a lot faster than running the clock sweep. That's why I think it'd be better to have the bgwriter run the clock sweep and put enough buffers on the free list to try and keep up with demand. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-hackers по дате отправления: