Re: Fixed length data types issue

From: mark(at)mark(dot)mielke(dot)cc
To: Gregory Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Martijn van Oosterhout <kleptog(at)svana(dot)org>
Subject: Re: Fixed length data types issue
Date: 2006-09-11 23:51:29
Message-ID: 20060911235129.GA25508@mark.mielke.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 11, 2006 at 07:05:12PM -0400, Gregory Stark wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> > > At first I meant that as a reductio ad absurdum argument, but, uh,
> > > come to think of it why *do* we have our own arbitrary precision
> > > library? Is there any particular reason we can't use one of the
> > > existing binary implementations?
> > Going over to binary storage would trade off I/O speed for calculation
> > speed, which is probably not a win for everyone;
> Huh? Which would you expect binary to be worse at than decimal? I
> would expect it to be both faster and denser.

Representation is the difficult part.

> > and even more seriously, how are you going to represent decimal fractions
> > exactly? The fact that 0.01 is 0.01 and not just a near approximation
> > thereto is critical for a lot of our users.
> Certainly any arbitrary precision library isn't worth beans if it can't
> represent values accurately.

This isn't correct. Try representing 0.01 "accurately" in binary. See what
you come up with. :-)

> I'm not sure how gmp and the others represent their data but my
> first guess is that there's no particular reason the base of the
> mantissa and exponent have to be the same as the base the exponent
> is interpreted as. That is, you can store a base 10 exponent but
> store it and the mantissa in two's complement integers.

I don't think gmp does this, nor do I expect it would be trivial to
author a package that was both efficient, and could operate in any
base. I believe gmp operates in a base that is the size of the CPU
word, usually 32-bits or 64-bits. It does not offer ability to
calculate or store using base 10.

I've seen libraries that do an acceptable job storing items in base
1000 or higher for use in decimal calculations. I have no idea what
PostgreSQL itself does... :-)

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-09-12 00:05:04 pgbench is badly broken since July
Previous Message Gregory Stark 2006-09-11 23:05:12 Re: Fixed length data types issue