From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: New version of money type |
Date: | 2006-09-14 15:17:29 |
Message-ID: | 45097289.7070609@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
D'Arcy J.M. Cain wrote:
> On Thu, 14 Sep 2006 07:59:07 -0700
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:
>> D'Arcy J.M. Cain wrote:
>>> For years I have been promising that a 64 bit version of the money type
>>> was on the way. Here it is. So far it compiles and I have done some
>>> basic testing on it and it seems to work fine. Note that the currency
>>> symbol is also dropped on output as well but it is accepted on input.
>> Not to come down on your hard work, but isn't the money type deprecated?
>
> Not by me. :-)
Obviously ;), but it is deprecated by the project.
>
> The biggest argument about the money type is that it has an unrealistic
> limit. With this change we can go to almost one hundred thousand
> trillion dollars. That should handle even the US federal budget for a
> few more years.
Isn't that what numeric is for?
>
> The benefit of the money type is speed. Because internal operations
> are done on integers they can generally be handled by single CPU ops.
> My tests on the 64 bit version show 10% to 25% improvement over numeric
> for many operations.
Well that is certainly cool :) I will leave it to others to determine if
we should include it.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-14 15:20:30 | Re: [ADMIN] Vacuum error on database postgres |
Previous Message | Russ Brown | 2006-09-14 15:15:34 | Optimising a query requiring seqscans=0 |