From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Jennifer Trey <jennifer(dot)trey(at)gmail(dot)com> |
Cc: | "Massa, Harald Armin" <chef(at)ghum(dot)de>, Bill Moran <wmoran(at)potentialtech(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Now I am back, next thing. Final PGS tuning. |
Date: | 2009-04-08 18:16:19 |
Message-ID: | alpine.GSO.2.01.0904081316370.22528@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2009-04-08 19:13:27 | Re: Are there performance advantages in storing bulky field in separate table? |
Previous Message | Scott Marlowe | 2009-04-08 17:53:55 | Re: Now I am back, next thing. Final PGS tuning. |