D'Arcy J.M. Cain darcy@druid.net 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.
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);
I
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);
As
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 darcy@druid.net wrote:
On Thu, 12 Oct 2006 14:17:33 -0400
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain darcy@druid.net writes:
Cool. So what do I do with the
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 discussed and
D'Arcy J.M. Cain darcy@druid.net 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
On Thu, 21 Dec 2006 10:47:52 -0500
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain darcy@druid.net 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
On Thu, 12 Oct 2006 14:24:22 -0400
D'Arcy J.M. Cain darcy@druid.net wrote:
On Thu, 12 Oct 2006 14:17:33 -0400
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain darcy@druid.net writes:
Cool. So what do I do with the patch? Should I add the currency
symbol back in and commit or should I
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 the
D'Arcy J.M. Cain darcy@druid.net 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
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 responding to
D'Arcy J.M. Cain darcy@druid.net 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
On Thu, 12 Oct 2006 14:17:33 -0400
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain darcy@druid.net 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
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 J.M.
-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 Oosterhout
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
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 RMB and
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 large data
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
-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
of
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
-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 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 that
On Thu, 14 Sep 2006 10:35:03 -0400
D'Arcy J.M. Cain darcy@druid.net 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
. 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 darcy@druid.net wrote
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 darcy@druid.net | Democracy is
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's more terse than numeric and a
I
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 proposed
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 nothing to
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 darcy@druid.net | Democracy is three wolves
D'Arcy,
On 9/28/06 8:43 AM, D'Arcy J.M. Cain darcy@druid.net 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. :-)
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 it's:
* 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
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've
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 I've
* 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* much slower
D'Arcy,
On 9/28/06 10:12 AM, D'Arcy J.M. Cain darcy@druid.net 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
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 darcy@druid.net 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?
Martijn,
On 9/28/06 11:53 AM, Martijn van Oosterhout kleptog@svana.org 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
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 proposal
Martijn,
On 9/28/06 12:42 PM, Martijn van Oosterhout kleptog@svana.org 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
On Thu, Sep 28, 2006 at 01:29:57PM -0700, Luke Lonergan wrote:
Martijn,
On 9/28/06 12:42 PM, Martijn van Oosterhout kleptog@svana.org wrote:
- Only supports one currency (dollars)
What are the manifestations of this?
test=# select '100'::money;
money
-
$100.00
(1 row)
The
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/displaying than
On Thu, 28 Sep 2006 22:53:34 +0200
Martijn van Oosterhout kleptog@svana.org 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
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 kleptog@svana.org 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
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.
The
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 a different
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 several
other
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 other
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
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%
* 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 other
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 tables
* 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
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
On 2006-09-15, Martijn van Oosterhout kleptog@svana.org 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
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 is
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 a
On 2006-09-15, D'Arcy J.M. Cain darcy@druid.net 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
On Fri, 15 Sep 2006 15:14:10 -
Andrew - Supernews [EMAIL PROTECTED] wrote:
On 2006-09-15, D'Arcy J.M. Cain darcy@druid.net 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
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 2006-09-15, D'Arcy J.M. Cain darcy@druid.net 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_
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 int4out, or is it
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
int4out(10) -
On Fri, 15 Sep 2006 16:15:04 -
Andrew - Supernews [EMAIL PROTECTED] wrote:
On 2006-09-15, D'Arcy J.M. Cain darcy@druid.net 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
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.
darcy=# select
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 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 work fine.
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 it
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 the
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 the
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 providing
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
* 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 numeric
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
75 matches
Mail list logo
