Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
От | Peter Geoghegan |
---|---|
Тема | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |
Дата | |
Msg-id | CAM3SWZTB=yJu0JwY846t1ov6VVZN0PXH4J1vsffJde0REX3EpA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, May 7, 2014 at 11:50 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> Doesn't match my experience. Even with the current buffer manager >> there's usually enough locality to keep important pages in s_b for a >> meaningful time. I *have* seen workloads that should have fit into >> memory not fit because of double buffering. > > Same here. I think that it depends on whether or not you're thinking about the worst case. Most people are not going to be in the category you describe here. Plenty of people in the Postgres community run with very large shared_buffers settings, on non i/o bound workloads, and report good results - often massive, quickly apparent improvements. I'm mostly concerned with obsoleting the 8GB hard ceiling rule here. It probably doesn't matter whether and by how much one factor is worse than the other, though. I found the section "5.2 Temporal Control: Buffering" in the following paper, that speaks about the subject quite interesting: http://db.cs.berkeley.edu/papers/fntdb07-architecture.pdf -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: