Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2
От | |
---|---|
Тема | Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2 |
Дата | |
Msg-id | Pine.LNX.4.10.10008061619560.24207-100000@nemo.house обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
> > Is there a reason we can't perform the conversion and then copy the > > low-order bits manually, with some bit-shifting and masking? > > *What* low-order bits? The fundamental problem is we don't have 'em. OK, we represent 10.1 (decimal) with 1010.000110011..., repeating the 0011 pattern. In floating point representation, we say this is 2^3 * 1.010000110011..., repeating the 0011 pattern. But this dosen't work very well, because when we print it out it won't be exact, it will be some decimal number ending in a 0 or a 5. So when we read this out in decimal, we get 10.099999995, with a variable number of 9's depending on the precision we use. When we print this number out, we perform the decimal conversion, and then truncate the last decimal digit and round. So I guess the question is, why can't we perform 4-bit float -> 8-bit float conversion via a decimal conversion, irrespective of storing the thing in ASCII. Mabye the decimal conversion is too costly? Perhaps we could 1) mark 4-bit floats with a flag of some kind indicating whether or not the decimal conversion is necessary, and 2) avoid this conversion wherever possible, including giving people a warning when they use float4s in their tuples. Or mabye I'm just being dumb. Ian
В списке pgsql-general по дате отправления: