From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Jim Finnerty <jfinnert(at)amazon(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: On disable_cost |
Date: | 2019-12-11 06:23:51 |
Message-ID: | 6da76620383a421c2f4164bd314bab9499d2ec5c.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2019-12-10 at 15:50 -0700, Jim Finnerty wrote:
> As a proof of concept, I hacked around a bit today to re-purpose one of the
> bits of the Cost structure to mean "is_disabled" so that we can distinguish
> 'disabled' from 'non-disabled' paths without making the Cost structure any
> bigger. In fact, it's still a valid double. The obvious choice would have
> been to re-purpose the sign bit, but I've had occasion to exploit negative
> costs before so for this POC I used the high-order bit of the fractional
> bits of the double. (see Wikipedia for double precision floating point for
> the layout).
>
> The idea is to set a special bit when disable_cost is added to a cost.
> Dedicating multiple bits instead of just 1 would be easily done, but as it
> is we can accumulate many disable_costs without overflowing, so just
> comparing the cost suffices.
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.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Koichi Suzuki | 2019-12-11 06:38:03 | get_database_name() from background worker |
Previous Message | Amit Kapila | 2019-12-11 05:48:24 | Re: Windows buildfarm members vs. new async-notify isolation test |