From: | Radosław Smogura <rsmogura(at)softperience(dot)eu> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | rsmogura(at)softperience(dot)pl, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Application user name attribute on connection pool |
Date: | 2010-08-02 21:43:00 |
Message-ID: | 201008022343.00122.rsmogura@softperience.eu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> how would you handle scale factors? numeric represents a BCD data
> type, with a decimal fractional component. how would you represent,
> say, 10000.001 in your version? how would you add 1.001 to 10000.01
> in your binary representation?
I think about datastructure something like this
[precision 16bits][scale 15 bits][1 bit sign]int[n] (here n can be always
calculeted as the (size of datatype - 8) / 4.
In this way the number 10000.001 will be stored as the single element array
8,3,+,{10000001}
If scale is same typically in aggregate, then it's just adding this array of
integers.
If scales aren't same then one of argument's must be multiplied by 10^(scales
diff).
In this way the result of 1.001 + 10000.01 will be
1001 + 1000001*10 with scale 3.
I think there is no big algorithmic difference beteween nbase encoding, and
encoding on full bytes - becuase in nbase encoding the carry in addition you
take as the (a+b)/1000. Here the difference is only that carry will be taken
from shifting longs eg:
long l = a[0] + b[0];
carry = L >> 32;
s[0] = l & 0xffffff;
> PostgreSQL already has BIGINT aka INT8, which are 8 bytes, and can
> represent integers up to like 9 billion billion (eg, 9 * 10^18).
But I think about numbers with precision - you can use float for moneys, etc
(rounding problems), and dividing each value in application by some scale
isn't nice, too.
From | Date | Subject | |
---|---|---|---|
Next Message | Hu, William | 2010-08-02 22:49:39 | Postgresql database for distributed transactions |
Previous Message | Felipe de Jesús Molina Bravo | 2010-08-02 21:42:55 | Re: solaris slow |