On 15/09/2020 19:46, Andrey M. Borodin wrote:
>
>
>> 15 сент. 2020 г., в 16:36, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):
>>
>> Another patch version, fixed a few small bugs pointed out by assertion failures in the regression tests.
>>
>> - Heikki
>> <v19-0001-Add-support-for-building-GiST-index-by-sorting.patch>
>
> These changes in create_index.out do not seem correct to me
>
> SELECT * FROM point_tbl ORDER BY f1 <-> '0,1';
> f1
> -------------------
> - (0,0)
> (1e-300,-1e-300)
> + (0,0)
>
> I did not figure out the root cause yet. We do not touch anything related to distance computation..
Ah yeah, that's subtle. Those rows are considered to be equally distant
from (0, 1), given the precision of the <-> operator:
regression=# SELECT f1, f1 <-> '0,1' FROM point_tbl ORDER BY f1 <-> '0,1';
f1 | ?column?
-------------------+------------------
(0,0) | 1
(1e-300,-1e-300) | 1
(-3,4) | 4.24264068711929
(-10,0) | 10.0498756211209
(10,10) | 13.4536240470737
(-5,-12) | 13.9283882771841
(5.1,34.5) | 33.885985303662
(1e+300,Infinity) | Infinity
(NaN,NaN) | NaN
|
(10 rows)
It is arbitrary which one you get first.
It's not very nice to have a not-well defined order of rows in the
expected output, as it could change in the future if we change the index
build algorithm again. But we have plenty of cases that depend on the
physical row order, and it's not like this changes very often, so I
think it's ok to just memorize the new order in the expected output.
- Heikki