|
昨天和同学试了一下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方法。 （编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
