GiST rtree logic is not right
От | Tom Lane |
---|---|
Тема | GiST rtree logic is not right |
Дата | |
Msg-id | 28178.1119488962@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: GiST rtree logic is not right
Re: GiST rtree logic is not right |
Список | pgsql-hackers |
It occurred to me to wonder whether contrib/rtree_gist fixes the rtree bug documented here: http://archives.postgresql.org/pgsql-general/2004-03/msg01143.php The answer is unfortunately "no". In the regression database, install rtree_gist and do: regression=# create table gist_emp4000 as select * from slow_emp4000; SELECT regression=# create index grect2ind ON gist_emp4000 USING gist (home_base); CREATE INDEX regression=# select count(*) from gist_emp4000 where home_base << '(35565,5404),(35546,5360)';count ------- 2144 (1 row) The correct answer is regression=# select count(*) from slow_emp4000 where home_base << '(35565,5404),(35546,5360)';count ------- 2214 (1 row) Now this is noticeably better than the rtree implementation, which finds only 1363 rows, but broken is still broken :-( This is doubtless not as high priority as the concurrency stuff you are working on, but it'd be good to fix anyway. I was thinking of proposing that we move rtree_gist into the core --- but the case for it would be stronger if it worked correctly ... regards, tom lane
В списке pgsql-hackers по дате отправления: