Re: clog_buffers to 64 in 8.3?
От | Tom Lane |
---|---|
Тема | Re: clog_buffers to 64 in 8.3? |
Дата | |
Msg-id | 12784.1186073400@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: clog_buffers to 64 in 8.3? (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: clog_buffers to 64 in 8.3?
Re: clog_buffers to 64 in 8.3? |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: > Tom, >> I don't actually think that what Jignesh is testing is a particularly >> realistic scenario, and so I object to making performance decisions on >> the strength of that one measurement. > What do you mean by "not realistic"? What would be a realistic scenario? The difference between maxing out at 1200 sessions and 1300 sessions doesn't excite me a lot --- in most environments you'd be well advised to use many fewer backends and a connection pooler. But in any case the main point is that this is *one* benchmark on *one* platform. Does anyone outside Sun even know what the benchmark is, beyond the fact that it's running a whole lot of sessions? Also, you should not imagine that boosting NUM_CLOG_BUFFERS has zero cost. The linear searches used in slru.c start to look pretty questionable if we want more than a couple dozen buffers. I find it entirely likely that simply changing the constant would be a net loss on many workloads. regards, tom lane
В списке pgsql-hackers по дате отправления: