昨天和同学试了一下Postgresql的R-tree
table 就２列：id int; mbr Box;
其中在mbr上建了个r-tree索引。
当有１０，０００个tuple的时候，试了２个包含操作（操作符：~）和一个相交操作，系统竟然都是用的顺序查找
想想可能数据太少，于是又导入了３００，０００个tuple（由于在导入前已建索引，导入工作有点慢）
例1：explain select * from roadtest where mbr ~ Box'(29,29),(30,30)'
输出："Bitmap Heap Scan on roadtest (cost=6.27..1032.28 rows=362 width=36)"
" Recheck Cond: (mbr ~ '(30,30),(29,29)'::Box)"
" -> Bitmap Index Scan on roadtest_mbr_rindex (cost=0.00..6.27 rows=362 width=0)"
" Index Cond: (mbr ~ '(30,29)'::Box)"
终于用了r-tree,并且用r-tree的时间是25 ms，而不用r-tree的时间是250 ms,大概5倍。
但是不太清楚bitmap index是干吗的。
今天找了一下bitmap index是用在找相交的地方的。如下：
Bitmap Indexes ： Allows more than one index per operation,but low concurrency.
SELECT * FROM search_orders
WHERE start_date > now() AND status > 0
先找到所有A={start_date > now()} 和 B={status > 0}
然后取交集
但还是不知道我上面的查询就涉及到一个条件 怎么也用了bitmap index
但是，似乎r-tree并不一直适用，
例2：explain select * from roadtest where polygon(mbr) ~ point'(29,29)'
输出："Seq Scan on roadtest (cost=0.00..8451.52 rows=181084 width=36)"
" Filter: (polygon(mbr) ~ '(29,29)'::point)"
还是顺序查找的,ft
同时，也发现了Postgresql在空间数据操作的一些问题：
1。没有Box~point 的操作，结果只能先把Box转变为polygon,再来（如例2）
2。没有Box(path)的函数
这些问题可能和Postgresql的定位有关，毕竟Postgresql不是PostGIS。
