Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: "John D(dot) Burger" <john(at)mitre(dot)org>
Cc: PostgreSQL-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits
Date: 2005-12-12 21:36:41
Message-ID: 20051212213641.GD54639@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-patches

On Mon, Dec 05, 2005 at 08:24:16AM -0500, John D. Burger wrote:
> >>There are practical applications, eg, 1024-bit keys are fairly common
> >>objects in cryptography these days, and that equates to about 10^308.
> >>I don't really foresee anyone trying to run crypto algorithms with SQL
> >>NUMERIC arithmetic, though ...
> >
> >2046 bit keys are becoming more common. However, math using these keys
> >is
> >usually done modulo a product of two primes and there are ways of
> >doing the
> >calculations that are going to be much faster than doing them the way
> >Postgres does. So it is unlikely that anyone would be using Postgres'
> >numeric
> >type to do this in any case.
>
> Nonetheless, the fact that people can think of practical applications
> for numbers whose length is easily within a factor of two of the
> proposed limitation makes me squeamish about it being shrunk. Also, I
> would say the same arguments about doing math with NUMERICs suggest
> that saving a few byes in representation is not a big deal. On the few
> occasions where I have used NUMERICs, I didn't care about stuff like
> that.

I think that if there are any esoteric cases where people are doing
these kinds of things with numeric, they could probably be best answered
by offering a completely different system anyway, using a different type
name. The 5 people in the world doing this will just have to change
their code I guess... ;)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jim C. Nasby 2005-12-12 21:47:29 Re: pg_autovacuum
Previous Message Mike Rylander 2005-12-12 20:48:48 Re: Memory Leakage Problem

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruno Wolff III 2005-12-12 21:48:23 Re: space for optimalization: DISTINCT without index
Previous Message Tom Lane 2005-12-12 21:19:54 Anyone for adding -fwrapv to our standard CFLAGS?

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-12-12 23:01:01 Re: How much expensive are row level statistics?
Previous Message Michael Fuhr 2005-12-12 18:50:16 Re: How much expensive are row level statistics?