Re: database tuning

kelvan wrote:
> you know what you lot have left my original question this server is a
> temporary piece of shit
>
> my original question is what are the overheads for postgres but obviously no
> one knows or no one knows where a webpage containing this information is -_-
>
> overhead information i would to know is row overheads column overheads and
> header overheads for blocks and anything else i have missed

You said you had most of that in your original post:
> I have gathered some relevant information form the documentation such
> as all
> the data type sizes and the RM block information but I don't have any
> information on INDEX blocks or other general overheads

The index details are in the source, as I said in my first reply. It's
just that nobody here thinks that'll help you much.

> neither I nor the web app developer are Mac savvy hell as far as we have
> seen no Mac tec is Mac savvy either

So what on earth are you going to do with the index overhead figures?
Without accurate information on usage patterns, fill-factor, vacuuming
frequency etc. they aren't going to tell you anything.

Even if you could get an accurate figure for database size with less
effort than just generating test data, what would your next step be?

> as I have said your ideas sound good just not Mac oriented

The only idea I've seen mentioned is connection-pooling. I'm not sure
why that wouldn't work on a Mac.

Other comments were warning that 30,000 connections weren't do-able,
that de-normalising made poor use of your limited disk/memory and
pointing out solutions other people use.

Oh, and me asking for any info from your testing.

> nor are they to
> do with my original question I have never had trouble finding overhead
> information on any other DBMS I have used this is the first time I have had
> to ask for it and since this DBMS is open source I have to ask a community
> rather than a company

Again, since you said you had all the stuff from the manuals, the rest
is in the source. That's what the source is there for.

--
Richard Huxton
Archonet Ltd