Re: GiST penalty functions [PoC]

From: Andrew Borodin <borodin(at)octonica(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Михаил Бахтерев <mob(at)k(dot)imm(dot)uran(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Михаил Бахтерев <mike(dot)bakhterev(at)gmail(dot)com>
Subject: Re: GiST penalty functions [PoC]
Date: 2016-09-10 18:19:16
Message-ID: CAJEAwVFgUnE+hk8P0MCUmuzm05731jg2ZeqTA5stPPYUFQ8w-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>Personally I wouldn't be very happy about an IEEE754 assumption.
Ok, so let's avoid autoconf man. There is no real explanations of the
ground for this assumption, just a reference to paper of David
Goldberg (and there is no metion about IEEE754 is absoulte
everywhere). BTW, may be we can ask David Goldberg how to hack that
float properly? I do not see any math sense in this:

pack_float(float actualValue, int realm)
{
...
int realmAjustment = *((int*)&actualValue)/4;
float something = *((float*)&realmAdjustment)
...
}
No wonder it's not in libs.
Nither I see a way to implement it with ldexp siblings.
>I did go to the trouble of testing Postgres on a VAX and we fixed the few
instances where it had such dependencies for a net gain.
Greg, could you please point out those places to see how exaclty it
should be #ifdef'd?

Regrads, Andrey Borodin.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-09-10 19:09:40 Re: pg_sequence catalog
Previous Message Peter Geoghegan 2016-09-10 18:10:51 Re: Parallel tuplesort (for parallel B-Tree index creation)