From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Jim Nasby <jim(at)nasby(dot)net> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Clock sweep not caching enough B-Tree leaf pages? |
Date: | 2014-04-15 00:43:21 |
Message-ID: | 20140415004321.GZ2556@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Jim Nasby (jim(at)nasby(dot)net) wrote:
> I think it's important to mention that OS implementations (at least all I know of) have multiple page pools, each of which has it's own clock. IIRC one of the arguments for us supporting a count>1 was we could get the benefits of multiple page pools without the overhead. In reality I believe that argument is false, because the clocks for each page pool in an OS *run at different rates* based on system demands.
They're also maintained in *parallel*, no? That's something that I've
been talking over with a few folks at various conferences- that we
should consider breaking up shared buffers and then have new backend
processes which work through each pool independently and in parallel.
> I don't know if multiple buffer pools would be good or bad for Postgres, but I do think it's important to remember this difference any time we look at what OSes do.
It's my suspicion that the one-big-pool is exactly why we see many cases
where PG performs worse when the pool is more than a few gigs. Of
course, this is all speculation and proper testing needs to be done..
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-04-15 00:45:56 | Re: Clock sweep not caching enough B-Tree leaf pages? |
Previous Message | Stephen Frost | 2014-04-15 00:40:07 | Re: Excessive WAL generation and related performance issue |