Re: Reducing NUMERIC size for 8.3

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reducing NUMERIC size for 8.3
Date: 2007-09-26 18:01:43
Message-ID: b42b73150709261101u5f96a9eeqfeb5fae91c239115@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/24/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
>
> We previously discussed compressing the numeric data type for small values:
>
> http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php
>
> We didn't do this for 8.3 but in any case Tom did suggest we ought to reverse
> the weight and sign/dscale so we could do this sometime without introducing
> another incompatibility.
>
> I think we also should move the NumericData and declaration to numeric.c and
> make the Numeric type an opaque pointer for the rest of the source tree. That
> will catch any contrib modules or third-party modules which would be broken by
> any new data representation.
>
>
> --- numeric.h 27 Feb 2007 23:48:10 +0000 1.24
> +++ numeric.h 24 Sep 2007 16:07:24 +0100
> @@ -63,8 +63,8 @@
> typedef struct NumericData
> {
> int32 vl_len_; /* varlena header (do not touch directly!) */
> - int16 n_weight; /* Weight of 1st digit */
> uint16 n_sign_dscale; /* Sign + display scale */
> + int16 n_weight; /* Weight of 1st digit */
> char n_data[1]; /* Digits (really array of NumericDigit) */
> } NumericData;

would this break any application pulling a numeric field as binary
over the protocol?

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2007-09-26 19:02:26 Re: Improving the Performance of Full Table Updates
Previous Message Mark Wong 2007-09-26 16:23:02 Re: top for postgresql (ptop?)