X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 2AE819DCB79 for ; Thu, 26 Jan 2006 06:22:05 -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 56694-04 for ; Thu, 26 Jan 2006 06:22:06 -0400 (AST) Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id D832A9DCB61 for ; Thu, 26 Jan 2006 06:22:02 -0400 (AST) Received: from relay.icomedias.com (relay.icomedias.com [62.99.232.66]) by svr4.postgresql.org (Postfix) with ESMTP id 6D98B5AF1AC for ; Thu, 26 Jan 2006 10:22:05 +0000 (GMT) Received: from loki.icomedias.com ([10.192.17.128]) by relay.icomedias.com (8.13.4/8.13.4) with ESMTP id k0QALwsk023423; Thu, 26 Jan 2006 11:21:58 +0100 From: Mario Weilguni To: pgsql-performance@postgresql.org Subject: Re: Physical column size Date: Thu, 26 Jan 2006 12:22:03 +0100 User-Agent: KMail/1.9 Cc: Paul Mackay References: <786c2f6d0601260206k2201a548p48af7c7fc085d3b2@mail.gmail.com> In-Reply-To: <786c2f6d0601260206k2201a548p48af7c7fc085d3b2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601261222.03526.mweilguni@sime.com> X-Scanned-By: MIMEDefang 2.54 on 10.192.64.200 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.107 required=5 tests=[AWL=0.107] X-Spam-Score: 0.107 X-Spam-Level: X-Archive-Number: 200601/436 X-Sequence-Number: 16914 Am Donnerstag, 26. Januar 2006 11:06 schrieb Paul Mackay: > Hi, > > 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 > ); > > I then inerted a bit more than 19 million rows in each table (exactly the > same number of rows in each). > > 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) ! Given that a "char" field is supposed to be 1 byte in size and > a int4 4 bytes, shouldn't the tmp_A use a smaller disk space ? Or is it > that any value, whatever the type, requires at least 4 bytes to be stored ? I think this is caused by alignment.