Skip site navigation (1) Skip section navigation (2)

Re: time to stop tuning?

From: Rod Taylor <rbt(at)sitesell(dot)com>
To: David Parker <dparker(at)tazznetworks(dot)com>
Cc: Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: time to stop tuning?
Date: 2004-11-26 18:29:19
Message-ID: 1101493759.44437.302.camel@home (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Fri, 2004-11-26 at 12:13 -0500, David Parker wrote:
> I suspect the ultimate answer to our problem will be:
>    1) aggressive client-side caching
>    2) SQL tuning
>    3) more backend hardware

#0 might actually be using connection pooling and using cached query
plans (PREPARE), disabling the statistics daemon, etc.

For the plans, send us EXPLAIN ANALYZE output for each of the common

If you can try it, I'd give a try at FreeBSD or a newer Linux on your
system instead of Solaris. Older versions of Solaris had not received
the same amount of attention for Intel hardware as the BSDs and Linux
have and I would imagine (having not tested it recently) that this is
still true for 32bit Intel.

Another interesting test might be to limit the number of simultaneous
connections to 8 instead of 30 (client side connection retry) after
client side connection pooling via pgpool or similar has been installed.

Please report back with your findings.
Rod Taylor <rbt(at)sitesell(dot)com>

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2004-11-26 19:04:35
Subject: Re: time to stop tuning?
Previous:From: David ParkerDate: 2004-11-26 17:13:32
Subject: time to stop tuning?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group