Re: Clock sweep not caching enough B-Tree leaf pages?
От | Stephen Frost |
---|---|
Тема | Re: Clock sweep not caching enough B-Tree leaf pages? |
Дата | |
Msg-id | 20140415004321.GZ2556@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Clock sweep not caching enough B-Tree leaf pages? (Jim Nasby <jim@nasby.net>) |
Ответы |
Re: Clock sweep not caching enough B-Tree leaf pages?
|
Список | 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 whichhas it's own clock. IIRC one of the arguments for us supporting a count>1 was we could get the benefits of multiplepage pools without the overhead. In reality I believe that argument is false, because the clocks for each page poolin 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 thisdifference 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
В списке pgsql-hackers по дате отправления: