Re: database tuning - Mailing list pgsql-performance

From kelvan
Subject Re: database tuning
Date
Msg-id fjc2hb$2cd3$1@news.hub.org
Whole thread Raw
In response to database tuning  ("kelvan" <kicmcewen@windowslive.com>)
Responses Re: database tuning
Re: database tuning
List pgsql-performance
"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



pgsql-performance by date:

Previous
From: Robert Treat
Date:
Subject: Re: TB-sized databases
Next
From: Ron Mayer
Date:
Subject: Re: TB-sized databases