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
> 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
> 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
> 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
pgsql-performance by date
|Next:||From: Kevin Grittner||Date: 2007-12-11 00:15:51|
|Subject: Re: database tuning|
|Previous:||From: Pavel Stehule||Date: 2007-12-10 13:07:58|
|Subject: Re: Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.|