From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: reducing NUMERIC size for 9.1 |
Date: | 2010-07-29 17:20:06 |
Message-ID: | 27621.1280424006@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jul 28, 2010 at 3:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-07-29 17:20:20 | Re: string_to_array has to be stable? |
Previous Message | Joshua D. Drake | 2010-07-29 17:12:06 | Re: On Scalability |