precision - Efficiently Store Decimal Numbers with Many Leading Zeros in Postgresql -

a number like:

0.000000000000000000000000000000000000000123456 

is difficult store without large performance penalty available numeric types in postgres. question addresses similar problem, don't feel came acceptable resolution. 1 of colleagues landed on rounding numbers 15 decimal places , storing them as:

0.000000000000001 

so double precision numeric type can used prevents penalty associated moving decimal numeric type. numbers small purposes more or less functionally equivalent, because both small (and mean more or less same thing). however, graphing these results , when large portion of data set rounded looks exceptionally stupid (flat line on graph).

because storing tens of thousands of these numbers , operating on them, decimal numeric type not option performance penalty large.

i scientist, , natural inclination store these types of numbers in scientific notation, does't appear postgres has kind of functionality. don't need of precision in number, want preserve 4 digits or so, don't need 15 digits float numeric type offers. what advantages , disadvantages of storing these numbers in 2 fields this:

1.234 (real) -40 (smallint) 

where equivalent 1.234*10^-40? allow ~32000 leading decimals 2 bytes used store them , 4 bytes store real value, total of maximally 6 bytes per number (gives me exact number want store , takes less space existing solution consumes 8 bytes). seems sorting these numbers improved you'd need sort on smallint field first followed real field second.

you and/or colleague seem confused numbers can represented using floating point formats.

a double precision (aka float) number can store @ least 15 significant digits, in range 1e-307 1e+308. have think of scientific notation. remove zeroes , move exponent. if whatever have once in scientific notation has less 15 digits , exponent between -307 , +308, can stored is.

that means 0.000000000000000000000000000000000000000123456 can stored double precision, , you'll keep significant digits (123456). no need round 0.000000000000001 or that.

floating point numbers have well-known issue of exact representation of decimal numbers (as decimal numbers in base 10 not map decimal numbers in base 2), that's not issue (it's issue if need able exact comparisons on such numbers).