PostgreSQL的R-tree和一些空间类型

昨天和同学试了一下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。

还有一个，Postgresql的r-tree基本是沿用了Guttman的r-tree，没有引入BulkLoad方法。

原文地址：https://www.jb51.cc/postgresql/197503.html