From: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GiST rtree logic is not right |
Date: | 2005-06-23 07:05:14 |
Message-ID: | Pine.GSO.4.63.0506231102270.26882@ra.sai.msu.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hmm,
something is broken in HEAD. I recall it worked in STABLE, here is what I have
Welcome to psql 8.0.3, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
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
-------
2214
(1 row)
btw, Teodor, I noticed gist_print from gevel package doesn't works in HEAD
regression=# select * from gist_print('grect2ind') as t(level int, a box) where
level =1;
ERROR: function return row and query-specified return row do not match
DETAIL: Returned row contains 3 attributes, but query expects 2.
Oleg
On Wed, 22 Jun 2005, Tom Lane wrote:
> 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
>
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2005-06-23 08:11:16 | Re: commit_delay, siblings |
Previous Message | John Hansen | 2005-06-23 06:30:45 | Re: GiST rtree logic is not right |