Re: Fixed length data types issue - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixed length data types issue
Date
Msg-id 5231.1157999118@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixed length data types issue  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Fixed length data types issue  (Gregory Stark <gsstark@mit.edu>)
Re: Fixed length data types issue  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> Is this an 8.2 thing?

You are joking, no?

> If not, is Numeric508 applied?

No, that got rejected as being too much of a restriction of the dynamic
range, eg John's comment here:
http://archives.postgresql.org/pgsql-general/2005-12/msg00246.php

I think a more practical way of shaving 2 bytes from NUMERIC would be to
invent a fixed-2-byte-header variant of varlena.  That's something we
talked about in the NUMERIC thread but ultimately dropped --- it'd be
worth reconsidering along with the current ideas about multiple varlena
header formats, however.  The reason to not just make it use the
generalized varlena format under discussion is that it'd really like to
have at least 2-byte alignment; that would be enough to avoid
memcpy-for-alignment.

Another interesting subset of the problem is the inet/cidr datatypes,
which I think would be perfectly happy with the 1-byte-header variants
we've talked about --- AFAIR the inet code doesn't really have any
alignment requirements on its data, and it certainly doesn't need values
longer than 63 bytes.  So that subset of the concept might need to be
broken out as a separately usable thing too.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: Buildfarm vs. Linux Distro classification
Next
From: Tom Lane
Date:
Subject: Re: Buildfarm vs. Linux Distro classification