* Jim Nasby (j...@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
signature.asc
Description: Digital signature
