Re: Yet another fast GiST build - Mailing list pgsql-hackers

From Andrey M. Borodin
Subject Re: Yet another fast GiST build
Date
Msg-id 2E34EB00-EED2-4DC3-B750-B219602C11C0@yandex-team.ru
Whole thread Raw
In response to Re: Yet another fast GiST build  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Yet another fast GiST build  (Heikki Linnakangas <hlinnaka@iki.fi>)
Re: Yet another fast GiST build  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers

> 15 сент. 2020 г., в 22:07, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):
>
> 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
ifwe change the index build algorithm again. But we have plenty of cases that depend on the physical row order, and
it'snot like this changes very often, so I think it's ok to just memorize the new order in the expected output. 


I think this is valid reasoning. GiST choose subtree algorithm is not deterministic, it calls random(), but not in
testedpaths.  
I was thinking that machine epsilon is near 1e-300, but I was wrong. It's actually near 1e-15.

Actually, I just want to understand what changes between v18 and v19 changed on-page order of items. I look into patch
diffand cannot figure it out. There are only logging changes. How this affects scan? 

Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Next
From: Greg Nancarrow
Date:
Subject: Re: Parallel copy