Re: Page-at-a-time Locking Considerations - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Page-at-a-time Locking Considerations
Date
Msg-id 47A77F35.8030409@enterprisedb.com
Whole thread Raw
In response to Re: Page-at-a-time Locking Considerations  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera wrote:
> 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.  (I wonder whether
> pg_subtrans would occupy a big portion of shared buffers if we let it go
> unchecked).

Presumably we would have a fair way of accounting cache hits, and 
increase the usage_count accordingly. It should occupy just the right 
amount, in proportion of how often it's used vs. other buffers.

That definitely seems worthwhile to me. Not only because of any possible 
performance gains you might get, but perhaps even more importantly it 
would eliminate an option (clog_buffers) that you may need to tune 
manually otherwise.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Page-at-a-time Locking Considerations
Next
From: Alvaro Herrera
Date:
Subject: Re: Page-at-a-time Locking Considerations