Something's been bugging me

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Something's been bugging me
Date: 2007-09-29 13:58:09
Message-ID: 87k5q9vaj2.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


A while back in an off-hand comment Tom packed varlenas he mentioned that we
might want to have more types of toast pointers. Since then the idea of some
alternative column-wise partitioning scheme has come up and another idea I've
been tossing around is some kind of compression scheme which takes advantage
of information across rows.

The current varvarlena scheme doesn't leave any room for any expansion at all.
Every possible value of varlena headers is meaningful and could potentially
exist in a database. So any such scheme would be end any hope of binary
compatibility in the future and probably any hope of a migrator since it would
potentially expand existing data.

Now not every possible idea for these options would need space in the varlena
header but many would.

I'm wondering whether it doesn't make sense to lower VARATT_SHORT_MAX to 0x70
to allow for at least a small number of constant values which could indicate
some special type of datum. That could be used to indicate that a fixed size
pointer like a toast pointer follows. That could be used for something like
common value compression. [*]

I'm almost tempted to suggest lowering it as far as 0x3f which would give us a
whole bit. That would be necessary if we wanted to allow for variable length
fields with some alternate interpretation following the header such as some
very light compression scheme. But I'm pretty loath to give up as much as that
now for only a potential future gain.

[*] Yes, this does make the idea of keeping the VARHDRSZ/VARSHDRSZ offset in
the varlen header seem pretty silly; hindsight is 20/20 and all that.

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2007-09-29 14:23:59 Re: PG on NFS may be just a bad idea
Previous Message Bruce Momjian 2007-09-29 11:14:25 Re: [COMMITTERS] pgsql: Temporarily modify tsearch regression tests to suppress notice