Re: Final background writer cleanup for 8.3
От | Gregory Stark |
---|---|
Тема | Re: Final background writer cleanup for 8.3 |
Дата | |
Msg-id | 87lkc12la5.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Final background writer cleanup for 8.3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Final background writer cleanup for 8.3
Re: Final background writer cleanup for 8.3 |
Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Greg Smith <gsmith@gregsmith.com> writes: >> In the interest of closing work on what's officially titled the "Automatic >> adjustment of bgwriter_lru_maxpages" patch, I wanted to summarize where I >> think this is at ... > >> 2) Having backends write their own buffers out does not significantly >> degrade performance, as those turn into cached OS writes which generally >> execute fast enough to not be a large drag on the backend. > > [ itch... ] That assumption scares the heck out of me. It is doubtless > true in a lightly loaded system, but once the kernel is under any kind > of memory pressure I think it's completely wrong. I think designing the > system around this assumption will lead to something that performs great > as long as you're not pushing it hard. I think Heikki's experiments showed it wasn't true for at least some kinds of heavy loads. However I would expect it to depend heavily on just what kind of load the machine is under. At least if it's busy writing then I would expect it to throttle writes. Perhaps in TPCC there are enough reads to throttle the write rate to something the kernel can buffer. > If you're still fiddling with it then you probably aren't going to get > it right in the next few days. Perhaps you should think about whether > this can be left out entirely for 8.3 and revisited later. How does all of this relate to your epiphany that we should just have bgwriter be a full clock sweep ahead clock hand without retracing its steps? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: