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: