On Sun, Aug 2, 2009 at 10:04 PM, Chris Dunn wrote:
> The database is 8gb currently. Use to be a lot bigger but we removed all
> large objects out and developed a file server storage for it, and using
> default page costs for 8.4, I did have it changed in 8.1.4
You might want to play with lowerin
August 2009 11:26 PM
To: Chris Dunn
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Performance 8.4.0
On Fri, Jul 31, 2009 at 12:22 AM, Chris Dunn wrote:
> constraint_exclusion = on
This is critical if you need it, but a waste of CPU time if you don't.
Other than that your pa
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jul 31, 2009 at 12:22 AM, Chris Dunn wrote:
> > constraint_exclusion = on
>
> This is critical if you need it, but a waste of CPU time if you don't.
> Other than that your paramaters look good. Are you using the default
> page cost settings?
On Fri, Jul 31, 2009 at 12:22 AM, Chris Dunn wrote:
> constraint_exclusion = on
This is critical if you need it, but a waste of CPU time if you don't.
Other than that your paramaters look good. Are you using the default
page cost settings? I see you have 12 GB RAM; how big is your
database?
..
Your settings look reasonable, I'd bump up checkpoint_segments to at least
double where you've got it set at now to lower general overhead a bit. I
doubt that will help you much though.
If you're at 100% CPU with no I/O wait, typically that means you have some
heavy queries running that are g
Hi,
I would like to know if my configuration is ok, We run a web application with
high transaction rate and the database machine on Mondays / Tuesdays is always
at 100% CPU with no IO/Wait . the machine is a Dual Xeon Quad core, 12gb RAM,
4gb/s Fibre Channel on Netapp SAN, with pg_xlog on separ
