Re: Now I am back, next thing. Final PGS tuning.

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Now I am back, next thing. Final PGS tuning.
Дата
Msg-id alpine.GSO.2.01.0904081316370.22528@westnet.com
обсуждение исходный текст
Ответ на Re: Now I am back, next thing. Final PGS tuning.  (Jennifer Trey <jennifer.trey@gmail.com>)
Список pgsql-general
On Wed, 8 Apr 2009, Jennifer Trey wrote:

> shared_buffer = 1024MB # Kept it

As mentioned a couple of times here, this is a really large setting for
Windows.  Something like 256MB would work better, and you might even find
some people making a case for 64MB or less on Windows.  I don't really
know for sure myself.

> Is the effective cache only the one for the OS ? not for them combined ?

It is sizing the combination of the shared_buffers *plus* what you expect
in the OS buffer cache.  I normally look at the size of the OS buffer
cache before the PostgreSQL server is started as a rough estimate here.

> Since I use Java, prepared statements are quite natural.

Prepared statements are not prepared transactions.  It's unlikely you've
got any code that uses PREPARE TRANSACTION, so you shouldn't need to
increase max_prepared_transactions.

All three of the above are not really clear in the tuning guide on the
wiki, I'll do an update to improve those sections when I get a minute.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

В списке pgsql-general по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: Now I am back, next thing. Final PGS tuning.
Следующее
От: Robert Treat
Дата:
Сообщение: Re: Are there performance advantages in storing bulky field in separate table?