From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | GiST rtree logic is not right |
Date: | 2005-06-23 01:09:22 |
Message-ID: | 28178.1119488962@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2005-06-23 02:14:34 | Re: commit_delay, siblings |
Previous Message | Alon Goldshuv | 2005-06-23 00:14:28 | COPY FROM performance improvements |