Message-Id: <475D8257.EE98.0025.0@wicourts.gov>
Date: Mon, 10 Dec 2007 18:15:51 -0600
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: <pgsql-performance@postgresql.org>,
	"kelvan" <kicmcewen@windowslive.com>
Subject: Re: database tuning
References: <fja1je$2c22$1@news.hub.org>
	<1197016760.4255.474.camel@ebony.site> <fjc2hb$2cd3$1@news.hub.org>
	<dcc563d10712100858j7b55e68co5d0da0f8b82c19b1@mail.gmail.com>
	<fjki5a$uf1$1@news.hub.org>
In-Reply-To: <fjki5a$uf1$1@news.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On Mon, Dec 10, 2007 at  6:29 PM, in message <fjki5a$uf1$1@news.hub.org=
>,
"kelvan" <kicmcewen@windowslive.com> wrote:=20
=20
> i need a more powerful dbms one that can=20
> handle multi threading.
=20
If you're looking to handle a lot of concurrent users, PostgreSQL
has the power.  The threading issues really only impact the ability
to spread the work for a single large query over the processors.
For multiple users the work is spread over the processors just fine.
=20
> as i have said not my choice i know 5 gigs of ram wouldnt start a hot =
air=20
> balloon let alone support the user base i will have
=20
We've run a web site with two million hits per day, running 10
million SELECT queries and 1 million DML database transactions
(averaging over 10 million DML statements) per day on a machine
with 6 MB of RAM under PostgreSQL, so you might be surprised.
Your biggest problem is the single disk drive.  RAID not only
is critical for data integrity, it helps performance when your
data is not fully cached.
=20
> we cannot configure postgres on a mac to=20
> go over 200 connections for god knows what reason but we have found =
ways=20
> around that using the mac
=20
Well, with four processors there's no point to going above about
15 or 20 database connections.  Use one of the many excellent
options for connection pooling for better results.
=20
> i am using alot of codes using small int and bit in my database and=20
> de-normalising everying to keep the cnnections down and the data read=20
> ammount down but that can only do so much.
=20
Denormalization almost always requires more disk space.  That's
exactly what you should be trying to avoid.
=20
> my problem is read time which is why i want to compact the postgres =
blocks=20
> as much as possible keeping the data of the database in as small a =
location=20
> as possible.
=20
A much bigger issue from that regard will probably be dead space
from updated and deleted rows (plus from any rollbacks).  Have
you figured out what your VACUUM strategy will be?
=20
Without knowing more, it's hard to say for sure, but you might do
just fine if you can get a few more drives hooked up through a
decent RAID controller, and funnel your connection through a
connection pool.
=20
I hope this helps.
=20
-Kevin
=20