Re: Thoughts on NBASE=100000000
От | David Rowley |
---|---|
Тема | Re: Thoughts on NBASE=100000000 |
Дата | |
Msg-id | CAApHDvoq6UjYKTiSC=g2BW5kc8Z+fLgbrML1GSoYr3hYaUZ8sA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Thoughts on NBASE=100000000 ("Joel Jacobson" <joel@compiler.org>) |
Список | pgsql-hackers |
On Sun, 21 Sept 2025 at 17:09, Joel Jacobson <joel@compiler.org> wrote: > Is there a greater-than-zero chance we could want to modernizing numeric > for 64-bit hardware, even if it would require a change to its internals? I can't quite speak to the proposal for differentiating the two different on-disk formats, but assuming that's all above board, I think the answer has to depend on how much performance there is to be had from this change vs the complexity of the change. We don't really have information about either of those things here, so I think it's going to be hard to answer this question until more information is available. If you put the on-disk format issue to the side for now, could this change be mocked up quickly enough to demonstrate what sort of performance gains are available from this? For me, I do suspect the numbers will look nice for larger numerics, but since I've not studied that code in detail, I can't really predict what scale of numbers the performance will start looking very good and where it won't make any difference, or if there will be regression for smaller numbers. Maybe some nice graphs showing some performance numbers (and perhaps table size) of various scales of numerics would help drive some discussion. Also, FWIW, I suspect this is a good time to consider this proposal because, as far as I see it, since 2a600a93c, we've basically made a statement that we don't really care that much about 32-bit performance anymore. So it would seem a bit off if someone objected to your proposal on the grounds of not wanting to slow down 32-bit platforms. I'm also keen to understand how you'd propose to handle functions receiving 1 NumericVar in 1e8 base format and the other in 1e4 format? Do you propose to normalise those to 1e8 so the functions don't need to have any additional code to handle calculating between the two different formats? If so, how much overhead is there to the normalisation? I assume that there'd be plenty of read-only workloads that might never rewrite the on-disk data which would result in that conversion having to take place all the time. I assume that could make things slower rather than faster, especially so for smaller numeric types that wouldn't gain from having the 1e8 base. David
В списке pgsql-hackers по дате отправления: