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

 

昨天和同学试了一下PostgreSQL的R-tree

table 就2列:id int; mbr  box;
其中在mbr上建了个r-tree索引。
当有10,000个tuple的时候,试了2个包含操作(操作符:~)和一个相交操作,系统竟然都是用的顺序查找
想想可能数据太少,于是又导入了300,000个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,30),(29,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方法。

 

你可能感兴趣的:(PostgreSQL)