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  (Teodor Sigaev <teodor@sigaev.ru>)
Re: GiST rtree logic is not right  (Oleg Bartunov <oleg@sai.msu.su>)
Список 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 по дате отправления:

Предыдущее
От: "Alon Goldshuv"
Дата:
Сообщение: COPY FROM performance improvements
Следующее
От: "Qingqing Zhou"
Дата:
Сообщение: Re: commit_delay, siblings