Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Reducing the overhead of NUMERIC data

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>,pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Reducing the overhead of NUMERIC data
Date: 2005-11-02 18:46:44
Message-ID: 7386.1130957204@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Tue, 2005-11-01 at 17:55 -0500, Tom Lane wrote:
>> I don't think it'd be worth having 2 types.  Remember that the weight is
>> measured in base-10k digits.  Suppose for instance
>> 	sign		1 bit
>> 	weight		7 bits (-64 .. +63)
>> 	dscale		8 bits (0..255)

> I've coded a short patch to do this, which is the result of two
> alternate patches and some thinking, but maybe not enough yet.

What your patch does is

	sign		2 bits
	weight		8 bits (-128..127)
	dscale		6 bits (0..63)

which is simply pretty lame: weight effectively has a factor of 8 more
dynamic range than dscale in this representation.  What's the point of
being able to represent 1 * 10000 ^ -128 (ie, 10^-512) if the dscale
only lets you show 63 fractional digits?  You've got to allocate the
bits in a saner fashion.  Yes, that takes a little more work.

Also, since the internal (unpacked) calculation representation has a
much wider dynamic range than this, it'd probably be appropriate to add
some range checks to the code that forms a packed value from unpacked.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2005-11-02 18:53:07
Subject: Re: Reducing the overhead of NUMERIC data
Previous:From: Jim C. NasbyDate: 2005-11-02 18:45:44
Subject: Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags

pgsql-patches by date

Next:From: Jim C. NasbyDate: 2005-11-02 18:53:07
Subject: Re: Reducing the overhead of NUMERIC data
Previous:From: Jim C. NasbyDate: 2005-11-02 18:45:44
Subject: Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group