Re: [HACKERS] regression bigtest needs very long time
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] regression bigtest needs very long time |
Дата | |
Msg-id | 19945.930666698@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] regression bigtest needs very long time (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] regression bigtest needs very long time
|
Список | pgsql-hackers |
Bruce Momjian <maillist@candle.pha.pa.us> writes: >> needs 4 cycles instead of 10 (because the decimal point has >> the same meaning in base 10000 the last value is stored >> internally as short ints 1, 2030, 1234, 5000). This is the >> worst case and it still saved 60% of the innermost cycles! > Interesting. How do other Db's do it internally? Anyone know? Probably the same way, if they want to be portable. What Jan is describing is a *real* standard technique (it's recommended in Knuth). AFAIK the only other way to speed up a digit-at-a-time implementation is to drop down to the assembly level and use packed-decimal instructions ... if your machine has any ... One thing worth thinking about is whether the storage format shouldn't be made the same as the calculation format, so as to eliminate the conversion costs. At four decimal digits per int2, it wouldn't cost us anything to do so. regards, tom lane PS: BTW, Jan, if you do not have a copy of Knuth's volume 2, I'd definitely recommend laying your hands on it for this project. His description of multiprecision arithmetic is the best I've seen anywhere. If we thought that the math functions (sqrt, exp, etc) for numerics were really getting used for anything, it might also be fun to try to put in some better algorithms for them. I've got a copy of Cody and Waite, which has been the bible for such things for twenty years. But my guess is that it wouldn't be worth the trouble, except to the extent that it speeds up the regression tests ;-)
В списке pgsql-hackers по дате отправления: