Tom Lane <[EMAIL PROTECTED]> writes:
> It would be a lot easier to sell that if it gave the right answers ;-)
Of course given that the real rtree index gives the wrong answers perhaps
moving rtree_gist into core (after fixing this) is just a bug fix :)
--
greg
---(end
"John Hansen" <[EMAIL PROTECTED]> writes:
>> I'll look at problem after GiST concurrency. Fixing
>> rtree_gist is bug a fix, not a new feature, so I'm not
>> limited by 1 July.
> Wont fixing rtree(_gist) require initdb, since the behaviour of the
> operators will change?
Possibly, but we never
Oleg Bartunov writes:
> something is broken in HEAD. I recall it worked in STABLE, here is what I have
No, actually it is broken in 8.0 too. The difference is that 8.0
defaults to not using an indexscan for this query. In 8.0 I see:
regression=# set enable_seqscan TO 1;
SET
regression=# explai
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 semicolo
> I'll look at problem after GiST concurrency. Fixing
> rtree_gist is bug a fix, not a new feature, so I'm not
> limited by 1 July.
Wont fixing rtree(_gist) require initdb, since the behaviour of the
operators will change?
... John
---(end of broadcast)
I'll look at problem after GiST concurrency. Fixing rtree_gist is bug a fix, not
a new feature, so I'm not limited by 1 July.
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
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
