Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id D658F4760AA for ; Tue, 8 Oct 2002 10:37:59 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 14D70475BD7 for ; Tue, 8 Oct 2002 10:37:59 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g98Ec2hR001929; Tue, 8 Oct 2002 10:38:02 -0400 (EDT) To: Ron Johnson Cc: pgsql-performance@postgresql.org Subject: Re: [GENERAL] Large databases, performance In-reply-to: <1034085052.1094.14.camel@haggis> References: <3DA1E50F.4394.107FF85D@localhost> <3DA2BE03.3674.13CF7DD1@localhost> <20021008072047.GB558@svana.org> <1034085052.1094.14.camel@haggis> Comments: In-reply-to Ron Johnson message dated "08 Oct 2002 08:50:52 -0500" Date: Tue, 08 Oct 2002 10:38:02 -0400 Message-ID: <1928.1034087882@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/60 X-Sequence-Number: 77 Ron Johnson writes: > Not only that, but you get INSERT, UPDATE, DELETE and SELECT performance > gains with fixed length records, since you don't get fragmentation. That argument loses a lot of its force when you consider that Postgres uses non-overwriting storage management. We never do an UPDATE in-place anyway, and so it matters little whether the updated record is the same size as the original. >> Well, maybe. But since 7.1 or so char() and varchar() simply became text >> with some length restrictions. This was one of the reasons. It also >> simplified a lot of code. > How much simpler can you get than fixed-length records? It's not simpler: it's more complicated, because you need an additional input item to figure out the size of any given column in a record. Making sure that that info is available every place it's needed is one of the costs of supporting a feature like this. regards, tom lane