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

Re: database tuning

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: kelvan <kicmcewen(at)windowslive(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: database tuning
Date: 2007-12-10 16:58:38
Message-ID: dcc563d10712100858j7b55e68co5d0da0f8b82c19b1@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Dec 7, 2007 1:13 PM, kelvan <kicmcewen(at)windowslive(dot)com> wrote:

> ok heres the thing i dont have a choice i just have to work with whats given
> whether it is good or not why i need these overheads is for block
> calculations and and tablespace calculations i have to keep everything in a
> very very small area on the hdd for head reading speed as the server i am
> forced to use is a peice of crap so i need to do my calculations to resolve
> this
>
> it is not that i dont know how to do my job i understand effective indexing
> materlized views and all other effects of database tuning is was my major
> aspect in my study i just need to know the numbers to do what i have to do.
>
> i am new to postgres i have used many other database management systems i
> know the over heads for all of them just not this one if someone could
> please be of assisstance.
>
> let me give a breef outlay of what i have without breaking my confidentality
> agreement
>
> mac server mac os 10.x
> postgres 8.2.5 (appologies i just got updated documentation with errors
> fixed in it)
> 70gig hdd
> 5 gig ram
> 4 cpus (not that it matters as postgres is not multi threading)

Uh, yeah it matters, postgresql can use multiple backends just fine.
But this will be the least of your problems.

> and i have to support approxmatally anywhere from 5000 - 30000 users all
> using it concurentally

You are being set up to fail.  No matter how you examine things like
the size of individual fields in a pg database, this hardware cannot
possibly handle that kind of load.  period.  Not with Postgresql, nor
with oracle, nor with teradata, nor with any other db.

If you need to have 30k users actually connected directly to your
database you most likely have a design flaw somewhere.  If you can use
connection pooling to get the number of connections to some fraction
of that, then you might get it to work.  However, being forced to use
a single 70G hard drive on an OSX machine with 5 Gigs ram is sub
optimal.

> as you can see this server wouldnt be my first choice (or my last choice)
> but as i said i have not choice at this time.

Then you need to quit.  Now.  And find a job where you are not being
setup to fail.  Seriously.

> the interface programmer and i have come up with ways to solve certian
> problems in preformance that this server produces but i still need to tune
> the database

You're being asked to take a school bus and tune it to compete at the indy 500.

In response to

Responses

pgsql-performance by date

Next:From: Kevin GrittnerDate: 2007-12-11 00:15:51
Subject: Re: database tuning
Previous:From: Pavel StehuleDate: 2007-12-10 13:07:58
Subject: Re: Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.

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