for now the only rtree index that work not so bad is the sqlite3
implementation ....
but because no multi-user (only lock table mecanisme in update), they
are at the end very slow :(

in postgreSQL it's not really efficient at all (0.5 seconds for 10 000
rows) and they even remove
they rtree Index to replace with they PostGIS extension

this why i thing the rtree index can be a killer application in firebird
nowadays, everyone need to do query like where price < xxx or price >
xxx or price between xxx and yyy, etc ....

rtree are here for that !

On 12/27/2010 1:36 PM, Thomas wrote:
>
>
>
> -- In firebird-support@yahoogroups.com
> <mailto:firebird-support%40yahoogroups.com>, Vander Clock Stephane > I
> completely agree ! actually i face the need to split my database in 2
> > database engines just because i need RTree indexes ...
> > PostgresSQL is probably right (i not try it yet), but it's a very heavy
> > system, it's hard like oracle without the power of oracle !
>
> This is getting off-topic now, but PostgreSQL is definitely not as
> "hard" or "heavy" as Oracle.
>
> Having 2 DBMS for a single application surely does not make sense.
>
> So you'll need to make a decision and take the DBMS that covers most
> of your needs. You'll probably never find a one that supports all
> features you need.
>
> If you need a small, fast, embeddable DBMS that supports spacial data
> and you don't really need good support for multi-user concurrency,
> then go for SQLite.
>
> If you need a small, fast embeddable DBMS that scales with concurrency
> in a multi-user environment but you can live without special support,
> then go for Firebird.
>
> If you need a fast and powerful DBMS that supports concurrent
> multi-user access including spacial support but you can live without
> embedding it, then go for PostgreSQL with the PostGIS extension
>
>


[Non-text portions of this message have been removed]