Re: reducing NUMERIC size for 9.1 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: reducing NUMERIC size for 9.1
Date
Msg-id 27621.1280424006@sss.pgh.pa.us
Whole thread Raw
In response to Re: reducing NUMERIC size for 9.1  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: reducing NUMERIC size for 9.1
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jul 28, 2010 at 3:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> No, you can do something like this:
>> 
>> typedef union numeric
>> {
>>        uint16  word1;
>>        numeric_short   short;
>>        numeric_long    long;
>> } numeric;

> That doesn't quite work because there's also a varlena header that has
> to be accounted for, so the third member of the union can't be a
> simple uint16.

Yeah, you would need an additional layer of struct to represent the
numeric with a length word in front of it.  I think this is not
necessarily bad because it would perhaps open the door to working
directly with short-varlena-header values, which is never going to
be possible with this:

> typedef struct NumericData
> {
>     int32           varlen;
>     int16           n_header;
>     union { ...

OTOH alignment considerations may make that idea hopeless anyway.


> Why n_data as char[1] instead of NumericDigit, you ask?

Yes, we'd have to export NumericDigit if we wanted to declare these
structs "properly" in numeric.h.  I wonder if that decision should
be revisited.  I'd lean to making the whole struct local to numeric.c
though.  Is there anyplace else that really ought to see it?


>> I hadn't actually looked.  I think though that it's a mistake to break
>> compatibility on both dscale and weight when you only need to break one.
>> Also, weight is *certainly* uninteresting for NaNs since it's not even
>> meaningful unless there are digits.  dscale could conceivably be worth
>> something.

> I don't think I'm breaking compatibility on anything.  Can you clarify
> what part of the code you're referring to here?  I'm sort of lost.

On-disk is what I'm thinking about.  Right now, a NaN's first word is
all dscale except the sign bits.  You're proposing to change that
but I think it's unnecessary to do so.  If we do it the way I'm
thinking, dscale would still mean the same in a NaN, and we'd simply
be ignoring the weight field (which might or might not be there
physically).
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: On Scalability
Next
From: Robert Haas
Date:
Subject: Re: string_to_array has to be stable?