Re: 7.3.1 New install, large queries are slow
От | Tom Lane |
---|---|
Тема | Re: 7.3.1 New install, large queries are slow |
Дата | |
Msg-id | 21623.1042865371@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 7.3.1 New install, large queries are slow (Jeff <threshar@torgo.978.org>) |
Ответы |
Re: 7.3.1 New install, large queries are slow
Re: 7.3.1 New install, large queries are slow |
Список | pgsql-performance |
Jeff <threshar@torgo.978.org> writes: > On Fri, 17 Jan 2003, Tom Lane wrote: >> Yeah, but isn't that theory a hangover from pre-Unix operating systems? > Informix, oracle, etc all do raw device access bypassing the kernels > buffering, etc. So they need heaping gobules of memory to do the same > thing the kernel does.. D'oh, I believe Jeff's put his finger on it. You need lotsa RAM if you are trying to bypass the OS. But Postgres would like to work with the OS, not bypass it. > but since they know the exact patterns of data and > how things will be done they can fine tune their buffer caches to get much > better performance than the kernel (15-20% in informix's case) since the > kernel needs to be a "works good generally" They go to all that work for 15-20% ??? Remind me not to follow that primrose path. I can think of lots of places where we can buy 20% for less work than implementing (and maintaining) our own raw-device access layer. > perhaps a FAQ entry or comment in the shipped config about it? > I think if people realize it isn't quite the same as what it does in > oracle/informix/etc then they'll be less inclined to cranking it. Good thought. But we do need to set the default to something a tad more realistic-for-2003 than 64 buffers ... regards, tom lane
В списке pgsql-performance по дате отправления: