Re: [GENERAL] Large databases, performance

On Tue, 2002-10-08 at 09:38, Tom Lane wrote:
> Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)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.

Must you update any relative indexes, in order to point to the
new location of the record?

> >> 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.

With fixed-length, why? From the metadata, you can compute the intra-
record offsets. That's how it works with the commercial RDBMS that
I use at work.

On that system, even variable-length records don't need record-size
fields. Any repeating text (more that ~4 chars) is replaced with
run-length encoding. This includes the phantom spaces at the end
of the field.

> Making sure that that info is available every place it's needed is one
> of the costs of supporting a feature like this.

--
+------------------------------------------------------------+
| Ron Johnson, Jr. mailto:ron(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA http://members.cox.net/ron.l.johnson |
| |
| "they love our milk and honey, but preach about another |
| way of living" |
| Merle Haggard, "The Fighting Side Of Me" |
+------------------------------------------------------------+