Re: Alternative variable length structure

From: "J(dot) Andrew Rogers" <jrogers(at)neopolitan(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: Alternative variable length structure
Date: 2005-09-08 19:21:47
Message-ID: BF45DD5B.2D0C%jrogers@neopolitan.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/8/05 9:53 AM, "Josh Berkus" <josh(at)agliodbs(dot)com> wrote:
>
> Hmmm. Seems like these would be different data types from the standard ones
> we deal with. I can see the value for data warehousing, for example.
>
> Wouldn't this require creating, for example, a SHORTTEXT type? Or were you
> planning this to handle VARCHAR(6) and the like? If so, how would we deal
> with users who change the length via ALTER TABLE?

If I am reading the patch correctly (and I may not be), changing the length
via ALTER TABLE would not affect anything because the header length is
variable per type instance in the table. This appears to be an alternate
encoding for VARCHAR(n) and similar.

This is not dissimilar to how ASN.1 BER prefix encodes type lengths, an
encoding widely used in wire protocols. This can save quite a few bytes in
many cases, particularly when storing short byte strings (for ASN.1, even
integers and similar are encoded this way to shave bytes on them as well but
that seems excessive). It would be useful to see how encoding/decoding cost
balances out the more compact representation in terms of performance.

J. Andrew Rogers

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2005-09-08 19:34:25 Re: initdb profiles
Previous Message Andrew Dunstan 2005-09-08 18:22:28 Re: Alternative variable length structure