Re: Page-at-a-time Locking Considerations
| От | Simon Riggs |
|---|---|
| Тема | Re: Page-at-a-time Locking Considerations |
| Дата | |
| Msg-id | 1202374412.29242.191.camel@ebony.site обсуждение исходный текст |
| Ответ на | Re: Page-at-a-time Locking Considerations (Simon Riggs <simon@2ndquadrant.com>) |
| Список | pgsql-hackers |
On Mon, 2008-02-04 at 20:54 +0000, Simon Riggs wrote: > On Mon, 2008-02-04 at 20:03 +0000, Gregory Stark wrote: > > > I wonder how hard it would be to shove the clog into regular shared > > memory pages and let the clock sweep take care of adjusting the > > percentage of shared mem allocated to the clog versus data pages. > > There is a reason that's not been done... try it and see. > > Plus it doesn't fully resolve the main issue as described. On further thought, there may be a way to do as Greg suggests. We keep clog pages in shared buffers, but maintain a vestigial slru structure that provides fast lookup to the N most recently accessed pages. So we don't keep a physical slru buffer space anymore, we just keep pointers to shared buffers. Slru "I/O" then becomes a swapping of entries on the slru fast lookup structure, but hopefully not I/O out of shared_buffers. When we move out of clog buffers we *may* need to write the page immediately because of async LSNs, but that seems OK. That solution sounds weird at first, but seems much less yuck than mmap() style solutions. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: