From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Theo Schlossnagle <jesus(at)omniti(dot)com>, "Jim C(dot) Nasby" <jimn(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: New version of money type |
Date: | 2006-09-17 00:29:49 |
Message-ID: | 20060917002948.GL6548@kenobi.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Gregory Stark (stark(at)enterprisedb(dot)com) 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 just as an integer.
Right, which is fine, but for >64k (Actually, isn't it 10,000?),
operations could be done in 1 step using 64bit ints instead of in
multiple steps. On systems with fast 64bit integer ops (quite a few of
them out there these days...) this seems likely to be an improvement in
performance.
Of course, there's the question of how much of an improvement, how
complicated it makes the code, backwards-compatibility issues, and what
to do about the binary in/out operations.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-17 00:34:29 | Re: The enormous s->childXids problem |
Previous Message | Joshua D. Drake | 2006-09-17 00:28:24 | Re: Mid cycle release? |