Re: Now I am back, next thing. Final PGS tuning.
| От | Massa, Harald Armin |
|---|---|
| Тема | Re: Now I am back, next thing. Final PGS tuning. |
| Дата | |
| Msg-id | e3e180dc0904080738v470cf8cg3b72ff67a1bb683c@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Now I am back, next thing. Final PGS tuning. (Bill Moran <wmoran@potentialtech.com>) |
| Ответы |
Re: Now I am back, next thing. Final PGS tuning.
Re: Now I am back, next thing. Final PGS tuning. |
| Список | pgsql-general |
Bill, Jennifer,
"documenting" that for the wiki is still on my backlog; so, here:
shared_buffers of PostgreSQL on Windows != shared_buffers of PostgreSQL on Unix
My experience is that raising shared_memory on Windows above minimum+~20% is not helping performance; it's more effective to have that memory at Windows for caching. (at least up to server 2003)
Harald
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
LASIK good, steroids bad?
> *shared_buffers = 1024 # min 128kB or max_connections*16kB ## Also to low.
> Right? I've got 3GB to work with!*
Assuming that's equating to 1G, then the value is about right. Common
best practice is to set this value to 1/4 - 1/3 of the memory available
for PostgreSQL. You're saying you'll have ~3G for PG, so 1G is about
right to start with.
"documenting" that for the wiki is still on my backlog; so, here:
shared_buffers of PostgreSQL on Windows != shared_buffers of PostgreSQL on Unix
My experience is that raising shared_memory on Windows above minimum+~20% is not helping performance; it's more effective to have that memory at Windows for caching. (at least up to server 2003)
Harald
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
LASIK good, steroids bad?
В списке pgsql-general по дате отправления: