Re: reducing NUMERIC size for 9.1

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

In response to

Responses

Browse pgsql-hackers by date

  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