From: "kelvan" <kicmcewen@windowslive.com>
Subject: Re: database tuning
Date: Sat, 8 Dec 2007 07:13:36 +1200
Organization: Hub.Org Networking Services
Lines: 103
Message-ID: <fjc2hb$2cd3$1@news.hub.org>
References: <fja1je$2c22$1@news.hub.org>
 <1197016760.4255.474.camel@ebony.site>
Reply-To: "kelvan" <kicmcewen@windowslive.com>
To: pgsql-performance@postgresql.org


"Simon Riggs" <simon@2ndquadrant.com> wrote in message 
news:1197016760.4255.474.camel@ebony.site...
> 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@2ndquadrant.com> wrote in message 
news:1197016760.4255.474.camel@ebony.site...
> 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