From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ron Johnson <ron.l.johnson@cox.net>
Cc: pgsql-performance@postgresql.org
Subject: Re: [GENERAL] Large databases, performance
Date: Tue, 08 Oct 2002 10:38:02 -0400
Message-ID: <1928.1034087882@sss.pgh.pa.us> (raw)
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>
Ron Johnson <ron.l.johnson@cox.net> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, ron.l.johnson@cox.net, pgsql-performance@postgresql.org
Subject: Re: [GENERAL] Large databases, performance
In-Reply-To: <1928.1034087882@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox