Re: On disable_cost
От | Greg Stark |
---|---|
Тема | Re: On disable_cost |
Дата | |
Msg-id | CAM-w4HNHGuRBq_9UPvo-sFTxBVsLRQRd0GX+-rfp=Wo1GwH6jw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: On disable_cost (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
I think this would be ready to abstract away behind a few functions that could always be replaced by something else later...
However on further thought I really think just using a 32-bit float and 32 bits of other bitmaps or counters would be a better approach.
On Sun., Dec. 15, 2019, 14:54 Tom Lane, <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Dec 11, 2019 at 7:24 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>> Doesn't that rely on a specific implementation of double precision (IEEE)?
>> I thought that we don't want to limit ourselves to platforms with IEEE floats.
> Just by the way, you might want to read the second last paragraph of
> the commit message for 02ddd499. The dream is over, we're never going
> to run on Vax.
Still, the proposed hack is doubling down on IEEE dependency in a way
that I quite dislike, in that (a) it doesn't just read float values
but generates new ones (and assumes that the hardware/libc will react in
a predictable way to them), (b) in a part of the code that has no damn
business having close dependencies on float format, and (c) for a gain
far smaller than what we got from the Ryu code.
We have had prior discussions about whether 02ddd499 justifies adding
more IEEE dependencies elsewhere. I don't think it does. IEEE 754
is not the last word that will ever be said on floating-point arithmetic,
any more than x86_64 is the last CPU architecture that anyone will ever
care about. We should keep our dependencies on it well circumscribed.
regards, tom lane
В списке pgsql-hackers по дате отправления: