Re: Fixed length data types issue

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Gregory Stark <gsstark(at)mit(dot)edu>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Martijn van Oosterhout <kleptog(at)svana(dot)org>
Subject: Re: Fixed length data types issue
Date: 2006-09-09 13:20:15
Message-ID: 87hczh89dc.fsf@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> The performance costs of that seem pretty daunting, however, especially when
> you reflect that simply stepping over a varlena field would require
> memcpy'ing its length word to someplace.

I think if you give up on disk and in-memory representations being the same
then there are ways of finessing that. For example you could have all the
lengths together in the header prior to the variable length fields.

In a separate unrelated thought, if we bring back the idea of having logical
and physical field orders be distinct then we could also have the initial
table creation sort the fields to minimize padding. It won't always be perfect
but sometimes it could help quite a bit. It also wouldn't help much if you
start altering the table afterward but even then the next time you pg_dump and
reload you'll get a more efficient layout.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2006-09-09 15:47:41 Schedualed Server Downtime
Previous Message mark 2006-09-09 12:39:57 Re: Proposal for GUID datatype