From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Yet another fast GiST build |
Date: | 2020-02-23 20:58:18 |
Message-ID: | CA+hUKGK3D-X0ZvhLRUJf0wfpLKUuntj1ULc1V9_F0Ay5tNV+Jw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 20, 2020 at 10:14 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> 1. We expect floats to be in IEEE format, and the sort order of IEEE
> floats is mostly correlated to the binary sort order of the bits
> reinterpreted as an int. It isn't in some special cases, but for this
> use case we don't really care about that, we're just trying to
> encourage locality.
I suppose there is a big jump in integer value (whether signed or
unsigned) as you cross from positive to negative floats, and then the
sort order is reversed. I have no idea if either of those things is a
problem worth fixing. That made me wonder if there might also be an
endianness problem. It seems from some quick googling that all
current architectures have integers and floats of the same endianness.
Apparently this wasn't always the case, and some ARMs have a weird
half-flipped arrangement for 64 bit floats, but not 32 bit floats as
you are using here.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-02-23 21:49:12 | Re: pgsql: Add kqueue(2) support to the WaitEventSet API. |
Previous Message | Chapman Flack | 2020-02-23 17:24:00 | Ought binary literals to allow spaces? |