"D'Arcy J.M. Cain" writes:
> I changed this and a few other things. I didn't see any response to my
> question though. Shall I go ahead and commit now so that we can test
> in a wider setting? I haven't committed anything in years and I am
> hesitant to do so now without consencus.
FWIW, as lo
On Thu, 21 Dec 2006 10:47:52 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> One bug I see in it is that you'd better make the alignment 'd' if the
> type is to be int8. Also I much dislike these changes:
>
> - int32 i = PG_GETARG_INT32(1);
> + int64 i = PG_GETARG_INT32(1)
On Thu, 21 Dec 2006 10:47:52 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> One bug I see in it is that you'd better make the alignment 'd' if the
> type is to be int8. Also I much dislike these changes:
>
> - int32 i = PG_GETARG_INT32(1);
> + int64 i = PG_GETARG_INT32(1)
On Thu, 21 Dec 2006 10:47:52 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" writes:
> > Very good points. However, like the currency symbol issue I would like
> > to separate that into another discussion. The code already exists with
> > the warts you mention (and more) and this
"D'Arcy J.M. Cain" writes:
> Very good points. However, like the currency symbol issue I would like
> to separate that into another discussion. The code already exists with
> the warts you mention (and more) and this proposal is to fix one thing
> that will make it more useful to others. Let's
On Thu, 21 Dec 2006 00:21:08 -0800
David Fetter <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 20, 2006 at 08:44:07PM -0500, D'Arcy J.M. Cain wrote:
> > Now that 8.3 has been branched shall I go ahead and commit? As
> > discussed I will put the currency symbol back in just so that it can
> > be discusse
On Wed, Dec 20, 2006 at 08:44:07PM -0500, D'Arcy J.M. Cain wrote:
> On Thu, 12 Oct 2006 14:24:22 -0400
> "D'Arcy J.M. Cain" wrote:
> > On Thu, 12 Oct 2006 14:17:33 -0400
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> > > "D'Arcy J.M. Cain" writes:
> > > > Cool. So what do I do with the patch? Should
On Thu, 12 Oct 2006 14:24:22 -0400
"D'Arcy J.M. Cain" wrote:
> On Thu, 12 Oct 2006 14:17:33 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
> > "D'Arcy J.M. Cain" writes:
> > > Cool. So what do I do with the patch? Should I add the currency
> > > symbol back in and commit or should I resubmit the p
This thread has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
D'Arcy J.M. Cain wrote:
> On Thu, 12 Oct 2006 14:17:33 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
> > "D'Arcy
On Thu, 12 Oct 2006 14:17:33 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" writes:
> > Cool. So what do I do with the patch? Should I add the currency
> > symbol back in and commit or should I resubmit the patch to hackers for
> > further review?
>
> Well, one thing you definit
"D'Arcy J.M. Cain" writes:
> Cool. So what do I do with the patch? Should I add the currency
> symbol back in and commit or should I resubmit the patch to hackers for
> further review?
Well, one thing you definitely *don't* do is commit right now, because
we're in feature freeze, not to mention
On Thu, 12 Oct 2006 13:21:37 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> > Well, the patch I submitted is definitely an improvement over the
> > existing version. Are you saying that I have to make further
> > improvements before these ones can be imported?
>
> I didn't say that. I was respondin
"D'Arcy J.M. Cain" writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Well, my perception of that has always been "it needs to be upgraded or
>> removed". So if D'Arcy wants to work on the improvement angle, I have
>> no problem with him doing so. The thing we need to negotiate is "how
>> much imp
On Thu, 28 Sep 2006 23:23:30 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> > The existing type is depricated and has been since at least 8.1; so yes,
> > it's slated for removal.
>
> Well, my perception of that has always been "it needs to be upgraded or
> removed". So if D'Arcy wants to work on th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Sep 30, 2006 at 01:00:05PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
[...]
> Oh BTW: 10^14 is not enough dynamic range --- those guys push around
> *serious* amounts of money. Bill Gates' net wealth is somewhere north
>
There'll also times a country may transit from one currency to
another. Even a currency (currency of most continental European
countries before Euro) is no more being used, it may still need to
be supported.
The "money" type is far too simplistic to model this kind of thing. A
really sophistic
David Fetter <[EMAIL PROTECTED]> writes:
> The "money" type is far too simplistic to model this kind of thing. A
> really sophisticated representation of money would have to take time,
> inflation/deflation, pairwise exchange rates, etc. into account. It
> would look more like a schema with a lar
On Sat, Sep 30, 2006 at 11:36:04AM -0400, Xiaofeng Zhao wrote:
> >I feel silly for even mentioning this, but there are less than 256
> >countries in the UN, and as far as I know, each has at most one
> >currency, so you could use 8 bits instead of 15.
> >
> That's not always true, e.g. China has RM
I feel silly for even mentioning this, but there are less than 256
countries in the UN, and as far as I know, each has at most one
currency, so you could use 8 bits instead of 15.
That's not always true, e.g. China has RMB and HKD. Also Taiwan is not a
member country of UN but I don't think one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Sep 29, 2006 at 10:43:53PM -0700, David Fetter wrote:
> On Sat, Sep 30, 2006 at 04:42:13AM +, [EMAIL PROTECTED] wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Fri, Sep 29, 2006 at 12:19:07PM +0200, Martijn van Oost
On Sat, Sep 30, 2006 at 04:42:13AM +, [EMAIL PROTECTED] wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, Sep 29, 2006 at 12:19:07PM +0200, Martijn van Oosterhout wrote:
> > On Thu, Sep 28, 2006 at 06:32:11PM -0500, Jim C. Nasby wrote:
> If you are at that, it's worth noting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Sep 29, 2006 at 12:19:07PM +0200, Martijn van Oosterhout wrote:
> On Thu, Sep 28, 2006 at 06:32:11PM -0500, Jim C. Nasby wrote:
> > What would be ideal is a money type that stored what currency was used
> > and let you change precision (within
On Thu, Sep 28, 2006 at 06:32:11PM -0500, Jim C. Nasby wrote:
> What would be ideal is a money type that stored what currency was used
> and let you change precision (within reason).
The taggedtypes version of currency does half of that, by storing the
currency and allowing the output format to de
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> I think it's also important to protect for the possibility of a more
> complete (and probably incompatible) type in the future, such as one
> that stores what currency a value is in.
Well, such a type could be called "currency", "cash", "forex" or sever
On Thu, Sep 28, 2006 at 11:23:30PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Thu, Sep 28, 2006 at 05:19:47PM -0400, D'Arcy J.M. Cain wrote:
> >> Well, it is already included. The current proposal is simply to
> >> improve the existing type. I guess you are arguing
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, Sep 28, 2006 at 05:19:47PM -0400, D'Arcy J.M. Cain wrote:
>> Well, it is already included. The current proposal is simply to
>> improve the existing type. I guess you are arguing a different
>> proposal altogether - to remove the existing type.
On Thu, Sep 28, 2006 at 05:19:47PM -0400, D'Arcy J.M. Cain wrote:
> On Thu, 28 Sep 2006 22:53:34 +0200
> Martijn van Oosterhout wrote:
> > Every new type needs to have a well-defined use-case before it can be
> > considered for includion.
>
> Well, it is already included. The current proposal is
On Thu, 28 Sep 2006 22:53:34 +0200
Martijn van Oosterhout wrote:
> Every new type needs to have a well-defined use-case before it can be
> considered for includion.
Well, it is already included. The current proposal is simply to
improve the existing type. I guess you are arguing a different
pro
On Thu, 28 Sep 2006 11:39:31 -0700
"Luke Lonergan" <[EMAIL PROTECTED]> wrote:
> > Numeric has been shown to be as good or better than money in I/O
> > operations.
>
> What exactly does that mean in the context of a Datum: "I/O operations"?
It means that numeric is better and parsing/storing/displ
On Thu, Sep 28, 2006 at 01:29:57PM -0700, Luke Lonergan wrote:
> Martijn,
>
> On 9/28/06 12:42 PM, "Martijn van Oosterhout" wrote:
>
> > - Only supports one currency (dollars)
>
> What are the manifestations of this?
test=# select '100'::money;
money
-
$100.00
(1 row)
The use of
Martijn,
On 9/28/06 12:42 PM, "Martijn van Oosterhout" wrote:
> - Only supports one currency (dollars)
What are the manifestations of this?
> - Only supports one scale (yen has no decimal normally, but what if you
> want to track hundredths of a dollar-cent?)
So, without a quantified benefit,
On Thu, Sep 28, 2006 at 11:57:10AM -0700, Luke Lonergan wrote:
> Got it - so the performance benefits of the fixed point versus Numeric are:
>
> - Smaller size of fixed point (less than half)
> - Faster arithmetic operations
>
> These should be quantified, so that we can evaluate Money64 as a pro
Martijn,
On 9/28/06 11:53 AM, "Martijn van Oosterhout" wrote:
> Converting to/from text format for when dealing with client
> applications. Numeric can convert faster than plain integers sometimes.
> Numeric isn't that slow really...
Got it - so the performance benefits of the fixed point versu
On Thu, Sep 28, 2006 at 11:39:31AM -0700, Luke Lonergan wrote:
> D'Arcy,
>
> On 9/28/06 10:12 AM, "D'Arcy J.M. Cain" wrote:
>
> > Numeric has been shown to be as good or better than money in I/O
> > operations.
>
> What exactly does that mean in the context of a Datum: "I/O operations"?
Conver
D'Arcy,
On 9/28/06 10:12 AM, "D'Arcy J.M. Cain" wrote:
> Numeric has been shown to be as good or better than money in I/O
> operations.
What exactly does that mean in the context of a Datum: "I/O operations"?
- Luke
---(end of broadcast)---
TI
* D'Arcy J.M. Cain (darcy@druid.net) wrote:
> On Thu, 28 Sep 2006 12:44:24 -0400
> Stephen Frost <[EMAIL PROTECTED]> wrote:
> > I'm not sure about 'money' in general but these claims of great
> > performance improvments over numeric just don't fly so easily with me.
> > numeric isn't all *that* muc
On Thu, 28 Sep 2006 12:44:24 -0400
Stephen Frost <[EMAIL PROTECTED]> wrote:
> I'm not sure about 'money' in general but these claims of great
> performance improvments over numeric just don't fly so easily with me.
> numeric isn't all *that* much slower than regular old integer in the
> tests that
Stephen,
On 9/28/06 9:44 AM, "Stephen Frost" <[EMAIL PROTECTED]> wrote:
> I'm not sure about 'money' in general but these claims of great
> performance improvments over numeric just don't fly so easily with me.
> numeric isn't all *that* much slower than regular old integer in the
> tests that I'
* Luke Lonergan ([EMAIL PROTECTED]) wrote:
> Though this may be the kiss of death, I favor a 64 bit float version of
> money. It's more terse than numeric and a *lot* faster when performing
> numeric operations because it would use a cpu intrinsic operand.
What about just having a numeric64, or
D'Arcy,
On 9/28/06 9:00 AM, "Luke Lonergan" <[EMAIL PROTECTED]> wrote:
> Which routines implement the money arithmetic?
Ok - so now having read the old documentation and the routine "
backend/utils/adt/cash.c" and the type definition for Cash in "
backend/include/utils/adt/cash.h" I can see that
D'Arcy,
On 9/28/06 8:43 AM, "D'Arcy J.M. Cain" wrote:
> On Thu, 28 Sep 2006 10:35:01 -0500
> "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>> Floating point math and hard-earned money are two things that don't mix
>> well. :)
>
> Using FP to track money is a good way to stop making any. :-)
Under
On Thu, 28 Sep 2006 10:35:01 -0500
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> Floating point math and hard-earned money are two things that don't mix
> well. :)
Using FP to track money is a good way to stop making any. :-)
--
D'Arcy J.M. Cain | Democracy is three wolves
http://www.dr
On Thu, Sep 28, 2006 at 11:32:37AM -0400, D'Arcy J.M. Cain wrote:
> On Thu, 28 Sep 2006 11:25:45 -0400
> "Luke Lonergan" <[EMAIL PROTECTED]> wrote:
> > Oic - so it's a floating point in an 8 byte int. That probably limits the
> > speed benefits, no?
>
> No, it's an int type. Floating point has
On Thu, 28 Sep 2006 11:25:45 -0400
"Luke Lonergan" <[EMAIL PROTECTED]> wrote:
> Oic - so it's a floating point in an 8 byte int. That probably limits the
> speed benefits, no?
No, it's an int type. Floating point has nothing to do with the money
type, either in the old 32 bit version or the pro
: Luke Lonergan
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New version of money type
On Thu, 28 Sep 2006 11:09:17 -0400
"Luke Lonergan" <[EMAIL PROTECTED]> wrote:
> Though this may be the kiss of death, I favor a 64 bit float version of
> money. It&#x
On Thu, 28 Sep 2006 11:09:17 -0400
"Luke Lonergan" <[EMAIL PROTECTED]> wrote:
> Though this may be the kiss of death, I favor a 64 bit float version of
> money. It's more terse than numeric and a
I assume you mean "...64 bit INT version..."
--
D'Arcy J.M. Cain | Democracy is three wo
7;Arcy J.M. Cain [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 28, 2006 11:02 AM Eastern Standard Time
To: D'Arcy J.M. Cain
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New version of money type
On Thu, 14 Sep 2006 10:35:03 -0400
"D'Arcy J.M. Cain&qu
On Thu, 14 Sep 2006 10:35:03 -0400
"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 d
On Sep 16, 2006, at 7:31 PM, Gregory Stark wrote:
Would that pose indexing issues? It would also mean that when
joining two
tables you'd have to handle some interesting type conversion
issues (at
times). We had someone accidentally create a largish table with
userid as
"numeric" and othe
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> In any case I think Jim was suggesting this be handled internally to the
> numeric data type which wouldn't cause this problem. However I'm not sure
> anything has to be done. A numeric is an array of 16 bit integers, so anything
> under 64k *is* stored
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> Would that pose indexing issues? It would also mean that when joining two
> tables you'd have to handle some interesting type conversion issues (at
> times). We had someone accidentally create a largish table with userid as
> "numeric" and other
* Theo Schlossnagle ([EMAIL PROTECTED]) wrote:
> Would that pose indexing issues? It would also mean that when
> joining two tables you'd have to handle some interesting type
> conversion issues (at times). We had someone accidentally create a
> largish table with userid as "numeric" and ot
On Sep 16, 2006, at 5:27 PM, Jim C. Nasby wrote:
On Thu, Sep 14, 2006 at 11:12:14AM -0400, D'Arcy J.M. Cain wrote:
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%
On Thu, Sep 14, 2006 at 11:12:14AM -0400, D'Arcy J.M. Cain wrote:
> 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 opera
On Fri, 15 Sep 2006 16:15:04 -
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> On 2006-09-15, "D'Arcy J.M. Cain" wrote:
> >> Seems? Have you benchmarked it?
> >
> > Not rigourously but a few "ANALYZE EXPLAIN" statements bear out this
> > observation.
>
> The overhead of EXPLAIN ANALYZE is so
On Fri, 15 Sep 2006 16:15:24 -
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> On 2006-09-15, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > Andrew - Supernews wrote:
> >> Numbers from an actual benchmark:
> >>
> >> int4out(0) - 0.42us/call
> >> numeric_out(0) - 0.32us/call
> >>
> >> int4o
On 2006-09-15, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews wrote:
>> Numbers from an actual benchmark:
>>
>> int4out(0) - 0.42us/call
>> numeric_out(0) - 0.32us/call
>>
>> int4out(10) - 0.67us/call
>> numeric_out(10) - 0.42us/call
>
> Is this really int4
On 2006-09-15, "D'Arcy J.M. Cain" wrote:
>> Seems? Have you benchmarked it?
>
> Not rigourously but a few "ANALYZE EXPLAIN" statements bear out this
> observation.
The overhead of EXPLAIN ANALYZE is so large that it completely swamps any
real difference.
>> The point is that bigint is _not_ fast
Andrew - Supernews wrote:
> Numbers from an actual benchmark:
>
> int4out(0) - 0.42us/call
> numeric_out(0) - 0.32us/call
>
> int4out(10) - 0.67us/call
> numeric_out(10) - 0.42us/call
Is this really int4out, or is it int8out?
--
Alvaro Herrera
On Fri, 15 Sep 2006 15:14:10 -
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> On 2006-09-15, "D'Arcy J.M. Cain" wrote:
> > On Fri, 15 Sep 2006 10:17:55 -
> > Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> >> Presumably the same speed as bigint, which is to say that while it is
> >> faste
On 2006-09-15, "D'Arcy J.M. Cain" wrote:
> On Fri, 15 Sep 2006 10:17:55 -
> Andrew - Supernews <[EMAIL PROTECTED]> wrote:
>> Presumably the same speed as bigint, which is to say that while it is
>> faster than numeric for calculation, it is (much) slower for input/output.
>> (The difference in
On Thu, 14 Sep 2006 14:12:30 -0400
AgentM <[EMAIL PROTECTED]> wrote:
> If you force the locale into the money type, then the entire column
> must be of the same currency. That seems like an unnecessary
> limitation. Does your type support banker's rounding?
The whole point of money is to have
On Fri, 15 Sep 2006 10:17:55 -
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> Presumably the same speed as bigint, which is to say that while it is
> faster than numeric for calculation, it is (much) slower for input/output.
> (The difference in speed between bigint output and numeric output i
On 2006-09-15, Martijn van Oosterhout wrote:
> Ofcorse, if this is a faster numeric type,
Presumably the same speed as bigint, which is to say that while it is
faster than numeric for calculation, it is (much) slower for input/output.
(The difference in speed between bigint output and numeric out
On Thu, Sep 14, 2006 at 01:56:16PM -0700, Josh Berkus wrote:
> Darcy,
>
> > The biggest argument about the money type is that it has an unrealistic
> > limit.
>
> Funny, I thought it was the lack of operators, conversions and any clear plan
> on how to have a money type that supports multiple c
Darcy,
> The biggest argument about the money type is that it has an unrealistic
> limit.
Funny, I thought it was the lack of operators, conversions and any clear plan
on how to have a money type that supports multiple currencies.
Or are you working on those? That would be keen ...
--
Josh
* D'Arcy J.M. Cain (darcy@druid.net) wrote:
> 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.
Erm, the numer
On Sep 14, 2006, at 14:04 , D'Arcy J.M. Cain wrote:
On Thu, 14 Sep 2006 10:33:19 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
By the way, I removed the currency symbol from the output. Would
removing the commas also make sense? These are the sorts of things
that can be added by applica
On Thu, 14 Sep 2006 10:33:19 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> > By the way, I removed the currency symbol from the output. Would
> > removing the commas also make sense? These are the sorts of things
> > that can be added by applications.
>
> I don't think that we should be p
D'Arcy J.M. Cain wrote:
On Thu, 14 Sep 2006 08:17:29 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
Obviously ;), but it is deprecated by the project.
I keep hearing that but no action is ever taken. I think that there
are too many people who still find it useful.
By the way, I removed t
On Thu, 14 Sep 2006 08:17:29 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> Obviously ;), but it is deprecated by the project.
I keep hearing that but no action is ever taken. I think that there
are too many people who still find it useful.
By the way, I removed the currency symbol from th
D'Arcy J.M. Cain wrote:
On Thu, 14 Sep 2006 07:59:07 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> 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 i
On Thu, 14 Sep 2006 07:59:07 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> 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 wor
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
74 matches
Mail list logo
