X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 241D79DCBD8 for ; Fri, 3 Mar 2006 06:23:24 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 20879-06 for ; Fri, 3 Mar 2006 06:23:25 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from gauss.credativ.com (ipx11302.ipxserver.de [212.112.227.254]) by postgresql.org (Postfix) with ESMTP id DB4329DC9F6 for ; Fri, 3 Mar 2006 06:23:21 -0400 (AST) Received: from bell.credativ.de (p50895799.dip.t-dialin.net [80.137.87.153]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by gauss.credativ.com (Postfix) with ESMTP id 3F5AFD75F2; Fri, 3 Mar 2006 11:23:23 +0100 (CET) From: Peter Eisentraut To: pgsql-general@postgresql.org Subject: Re: Physical column size Date: Fri, 3 Mar 2006 11:23:21 +0100 User-Agent: KMail/1.8.3 Cc: "Paul Mackay" References: <786c2f6d0601260206k2201a548p48af7c7fc085d3b2@mail.gmail.com> <786c2f6d0603030203m3b7c62a1k6950ceca066dc5ce@mail.gmail.com> In-Reply-To: <786c2f6d0603030203m3b7c62a1k6950ceca066dc5ce@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200603031123.22453.peter_e@gmx.net> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.104 required=5 tests=[AWL=0.104] X-Spam-Score: 0.104 X-Spam-Level: X-Archive-Number: 200603/115 X-Sequence-Number: 91980 Am Freitag, 3. März 2006 11:03 schrieb Paul Mackay: > I've created a table like this : > CREATE TABLE tmp_A ( > c "char", > i int4 > ); > > And another one > CREATE TABLE tmp_B ( > i int4, > ii int4 > ); > The end result is that the physical size on disk used by table tmp_A is > exactly the same as table tmp_B (as revealed by the pg_relation_size > function) ! An int4 field is required to be aligned at a 4-byte boundary internally, so there are 3 bytes wasted between tmp_A.c and tmp_A.i. If you switch the order of the fields you should see space savings. (Note, however, that the per-row overhead is about 32 bytes, so you'll probably only save about 10% overall, rather than the 37.5% that one might expect.) -- Peter Eisentraut http://developer.postgresql.org/~petere/