From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Page-at-a-time Locking Considerations |
Date: | 2008-02-04 21:05:18 |
Message-ID: | 8203.1202159118@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> 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.
> Hmm, this is an interesting idea. I wonder what would happen if we let
> other SLRU users go into shared buffers too -- for example it has been
> reported several times that pg_subtrans thrashing can cause severe
> problems in case of long running transactions.
My recollection is that we didn't do that because the standard buffer
manager has some assumptions that are violated by clog/etc pages ---
notably the lack of LSNs on the pages. Not sure how hard that is to
fix. I also note that we'd not really be removing any contention,
rather just pushing it into the bufmgr. Maybe the bufmgr is now
scalable enough that it could take the extra load better than SLRU can,
but this is hardly a given.
It sounds worth experimenting with, but it's not a slam-dunk win.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-02-04 21:08:29 | Re: Page-at-a-time Locking Considerations |
Previous Message | Simon Riggs | 2008-02-04 20:54:30 | Re: Page-at-a-time Locking Considerations |