Re: Fix picksplit with nan values

On Tue, Sep 17, 2013 at 5:04 PM, Alexander Korotkov <aekorotkov(at)gmail(dot)com>wrote:

> On Mon, Sep 16, 2013 at 4:13 PM, Andrew Gierth <
> andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>
>> >>>>> "Alexander" == Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
>>
>> Alexander> 2) NaN coordinates should be processed in GiST index scan
>> Alexander> like in sequential scan.
>>
>> postgres=# select * from pts order by a <-> '(0,0)' limit 10;
>> a
>> ----------
>> (1,1)
>> (7,nan)
>> (9,nan)
>> (11,nan)
>> (4,nan)
>> (nan,6)
>> (2,1)
>> (1,2)
>> (2,2)
>> (3,1)
>> (10 rows)
>>
>> postgres=# set enable_indexscan=false;
>> SET
>>
>> postgres=# select * from pts order by a <-> '(0,0)' limit 10;
>> a
>> -------
>> (1,1)
>> (2,1)
>> (1,2)
>> (2,2)
>> (3,1)
>> (1,3)
>> (3,2)
>> (2,3)
>> (4,1)
>> (1,4)
>> (10 rows)
>>
>> this data set was created by:
>> insert into pts
>> select point(i,j)
>> from (select generate_series(1,100)::float8 union all select 'nan')
>> s1(i),
>> (select generate_series(1,100)::float8 union all select 'nan')
>> s2(j)
>> order by random();
>
>
> Thanks, Andrew! Good spot.
> I didn't examine order by operators for work with NaNs.
> I think this time problem is in GiST itself rather than in opclass. I'm
> going to fix it in a separate patch.
>

Attached patch fixes knn GiST behaviour with NaN. It makes RB-tree
comparison function in GiST work like float8 btree opclass comparison
function.

------
With best regards,
Alexander Korotkov.