Message-ID: <6da76620383a421c2f4164bd314bab9499d2ec5c.camel@cybertec.at>
Subject: Re: On disable_cost
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Jim Finnerty <jfinnert@amazon.com>, pgsql-hackers@postgresql.org
Date: Wed, 11 Dec 2019 07:23:51 +0100
In-Reply-To: <1576018229539-0.post@n3.nabble.com>
References: 
	<CAO0i4_SSPV9TVxbbTRVLOnCyewopcc147fBZy=f2ABk15eHS+g@mail.gmail.com>
	 <CA+hUKGJ0NTtLB5dv5gbuDoRirtamC--wWGNoAT4=fF2Ev1bRdA@mail.gmail.com>
	 <20191101160038.wn3qkvp4psnatmm3@alap3.anarazel.de>
	 <CA+Tgmob4+Eu5LN4j1XEMQDtCFFLKuUCEJebND3bWrQL0-N7VTA@mail.gmail.com>
	 <1572625852934-0.post@n3.nabble.com>
	 <20191101170406.w6ybnafyvpxv2ltg@development>
	 <30025.1572707098@sss.pgh.pa.us> <1576018229539-0.post@n3.nabble.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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