Re: Clock sweep not caching enough B-Tree leaf pages?

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Jim Nasby <jim@nasby.net>
Cc: Peter Geoghegan <pg@heroku.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-04-15T00:43:21Z
Lists: pgsql-hackers
* Jim Nasby (jim@nasby.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

Commits

  1. Replace the BufMgrLock with separate locks on the lookup hashtable and