Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id E71A62E018F for ; Fri, 7 Dec 2007 04:13:03 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 01730-01 for ; Fri, 7 Dec 2007 04:12:58 -0400 (AST) Received: from pih-relay05.plus.net (pih-relay05.plus.net [212.159.14.132]) by postgresql.org (Postfix) with ESMTP id 254672E019D for ; Fri, 7 Dec 2007 04:13:00 -0400 (AST) Received: from [84.51.143.99] (helo=server3.office.archonet.com) by pih-relay05.plus.net with esmtp (Exim) id 1J0YKP-0006pJ-2E; Fri, 07 Dec 2007 08:12:57 +0000 Received: from [192.168.1.36] (dell36.office.archonet.com [192.168.1.36]) by server3.office.archonet.com (Postfix) with ESMTP id 9750327404C; Fri, 7 Dec 2007 08:12:55 +0000 (GMT) Message-ID: <47590087.7030409@archonet.com> Date: Fri, 07 Dec 2007 08:12:55 +0000 From: Richard Huxton User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: kelvan CC: pgsql-performance@postgresql.org Subject: Re: database tuning References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/94 X-Sequence-Number: 27910 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 [snip] > I am using postgres 8.1 if anyone can post links to pages containing over > head information and index block header information it would be most > appreciated as I cannot seem to find anything I'd look to the source if you care that strongly. Don't rely on any info found on the internet unless it explicitly mentions 8.1 - these things change. Have a look in "backend/storage/" and "backend/access/" I'd guess (not a hacker myself). Some thoughts though: 1. If you care that strongly about performance, start building it with 8.3 2. Does your testing show that index storage overheads are/will be a problem? If not, I'd concentrate on the testing to make sure you've identified the bottlenecks first. -- Richard Huxton Archonet Ltd