"Bruce Momjian" <bruce@momjian.us> writes:
> Greg, do you want to submit a patch for this or add a TODO item for this?
Well I never got any approval or rejection in principle so I don't know if
such a patch would be accepted even if it were implemented reasonably. If it
has the consensus needed to be a TODO item I would go ahead and do it.
The main design issue is that I was proposing to make it impossible to access
the internals of the numeric storage using macros. Currently some of the data
(the sign, dscale, and weight) is visible without having to call any special
numeric functions. I was proposing to use representations where those might
not be as easily accessible.
However I don't think we have any consumers of that data outside of numeric.c
anyways. Is there anything using that functionality currently? Do we mind
losing it?
> ---------------------------------------------------------------------------
>
> Gregory Stark wrote:
>>
>> I've uploaded a quick hack to store numerics in < 8 bytes when possible.
>>
>> http://community.enterprisedb.com/numeric-hack-1.patch
>>
>> This is a bit of a kludge since it doesn't actually provide any interface for
>> external clients of the numeric module to parse the resulting data. Ie, the
>> macros in numeric.h will return garbage.
>>
>> But I'm not entirely convinced that matters. It's not like those macros were
>> really useful to any other modules anyways since there was no way to extract
>> the actual digits.
>>
>> The patch is also slightly unsatisfactory because as I discovered numbers like
>> 1.1 are stored as two digits currently. But it does work and it does save a
>> substantial amount of space for integers.
>>
>> postgres=# select n,pg_column_size(n) from n;
>> n | pg_column_size
>> ----------+----------------
>> 1 | 2
>> 11 | 2
>> 101 | 2
>> 1001 | 3
>> 10001 | 9
>> 100001 | 9
>> 1.1 | 9
>> 10.1 | 9
>> 100.1 | 9
>> 1000.1 | 9
>> 10000.1 | 11
>> 100000.1 | 11
>>
>> I had hoped to get the second batch to be 3-4 bytes. But even now note how
>> much space is saved for integers <10000.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com