Re: Application user name attribute on connection pool

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.

In response to

Responses

Browse pgsql-general by date

  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