Re: database tuning

From: "kelvan" <kicmcewen(at)windowslive(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: database tuning
Date: 2007-12-07 19:13:36
Message-ID: fjc2hb$2cd3$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


"Simon Riggs" <simon(at)2ndquadrant(dot)com> wrote in message
news:1197016760(dot)4255(dot)474(dot)camel(at)ebony(dot)site(dot)(dot)(dot)
> On Fri, 2007-12-07 at 12:45 +1200, kelvan wrote:
>
>> hi i need to know all the database overhead sizes and block header sizes
>> etc
>> etc as I have a very complex database to build and it needs to be speed
>> tuned beyond reckoning
>
> If your need-for-speed is so high, I would suggest using 8.3 or at least
> looking at the 8.3 documentation.
>
> This release is very nearly production and is much faster than 8.1 or
> 8.2. You may not have realised that Postgres dot releases are actually
> major releases and have significant speed differences.
>
> There's not much to be done about the overheads you mention, so best to
> concentrate your efforts on index planning for your most frequently
> executed queries.
>
> --
> Simon Riggs
> 2ndQuadrant http://www.2ndQuadrant.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

"Simon Riggs" <simon(at)2ndquadrant(dot)com> wrote in message
news:1197016760(dot)4255(dot)474(dot)camel(at)ebony(dot)site(dot)(dot)(dot)
> On Fri, 2007-12-07 at 12:45 +1200, kelvan wrote:
>
>> hi i need to know all the database overhead sizes and block header sizes
>> etc
>> etc as I have a very complex database to build and it needs to be speed
>> tuned beyond reckoning
>
> If your need-for-speed is so high, I would suggest using 8.3 or at least
> looking at the 8.3 documentation.
>
> This release is very nearly production and is much faster than 8.1 or
> 8.2. You may not have realised that Postgres dot releases are actually
> major releases and have significant speed differences.
>
> There's not much to be done about the overheads you mention, so best to
> concentrate your efforts on index planning for your most frequently
> executed queries.
>
> --
> Simon Riggs
> 2ndQuadrant http://www.2ndQuadrant.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

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)

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

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.
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

if you need any other information for someone to give me the overheads then
please ask but i may not be able to tell you

regards
kelvan

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Ron Mayer 2007-12-07 20:46:21 Re: TB-sized databases
Previous Message Robert Treat 2007-12-07 17:45:08 Re: TB-sized databases