Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization)) - Mailing list pgsql-hackers

From Andrew Gierth
Subject Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization))
Date
Msg-id 87fvayhmtj.fsf@news-spur.riddles.org.uk
Whole thread Raw
Responses Re: Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization))
Re: Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization))
List pgsql-hackers
Another spinoff from the abbreviation discussion. Peter Geoghegan
suggested on IRC that numeric would benefit from abbreviation, and
indeed it does (in some cases by a factor of about 6-7x or more, because
numeric comparison is no speed demon).

This patch abbreviates numerics to a weight+initial digits
representation (the details differ slightly between 32bit and 64bit
builds to make the best use of the available bits).

On 32bit, numeric values that are between about 10^-44 and 10^83, and
which differ either in order of magnitude or in the leading 7
significant decimal digits (not base-10000 digits, single decimals) will
get distinct abbreviations. On 64bit the range is 10^-176 to 10^332 and
the first 4 base-10000 digits are kept, thus comparing 13 to 16 decimal
digits. This is expected to be ample for applications using numeric to
store numbers; applications that store things in numeric that aren't
actually numbers might not see the benefit, but I have not found any
detectable slowdown from the patch even on constructed pathological
data.

--
Andrew (irc:RhodiumToad)



Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: longjmp clobber warnings are utterly broken in modern gcc
Next
From: Robert Haas
Date:
Subject: Re: longjmp clobber warnings are utterly broken in modern gcc