On Tue, Sep 17, 2013 at 5:04 PM, Alexander Korotkov <aekorot...@gmail.com>wrote:
> On Mon, Sep 16, 2013 at 4:13 PM, Andrew Gierth < > and...@tao11.riddles.org.uk> wrote: > >> >>>>> "Alexander" == Alexander Korotkov <aekorot...@gmail.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.
fix-knn-gist-nan.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
