性能後代的搜索使用的Postgres intarray場

我有一個Postgres（版本9.5.4）表geo包含738884條記錄的國家地理數據的結構如下：由kind場性能後代的搜索使用的Postgres intarray場

   Table "public.geo" 
    Column |   Type    | Modifiers | Storage | Stats target | Description 
-------------+-----------------------------+-----------+----------+--------------+------------- 
id   | integer      | not null | plain |    | 
kind  | character varying(255)  |   | extended |    | 
name  | character varying(255)  |   | extended |    | 
is_owner | integer      |   | plain |    | 
path_array | integer[]     |   | extended |    | 
Indexes: 
    "geo_pkey" PRIMARY KEY, btree (id) 
    "kind_index" btree (kind) 
    "path_array_idx" gin (path_array gin__int_ops)

記錄有層次：country→province→area→locality。該層次結構存儲在path_array字段中，作爲祖先和行的自我ID的數組。

實施例：

17239123 locality Moscow 1 {17073865,17073877,17073958,17239123}

我已經安裝intarray延伸，並加入適當的索引path_array字段。

現在我有一堆recods的id可以有任何種類（從國家到地區），我需要選擇類型爲locality的所有後代（即在其path_array中有任何此ID的記錄）。

這是我的查詢：

SELECT 
    id 
FROM geo 
WHERE 
    kind = 'locality' 
    AND is_owner = 1 
    AND path_array && '{17073888,17073984,17073885,17073905,17073958,17073927,17073908,17073952,17073948,17073947,17073917,17073944,17073919,17073922,17073914,17073937,17073895,17073904,17073911,17073949,17073938,17073957,17073900,17073915,17073936,17073887,17073933,17073939,17073956,17073884,17073901,17073881,17153202,17073916,17073945,17073883,17073943,17073909,17073950,17073942,17073906,17073886,17073910,17073882,17073941,17073891,17073929,17073928,17073903,17073912,17073930,17073898,17073899,17073954}'::integer[]

這裏是EXPLAIN ANALYZE輸出：

Bitmap Heap Scan on geo (cost=1418.04..1532.99 rows=8 width=4) (actual time=685.183..723.330 rows=20984 loops=1) 
Recheck Cond: ((is_owner = 1) AND (path_array && '{17073888,17073984,17073885,17073905,17073958,17073927,17073908,17073952,17073948,17073947,17073917,17073944,17073919,17073922,17073914,17073937,17073895,17073904,17073911,17073949,17073938,17073957,17073900,17073915,17073936,17073887,17073933,17073939,17073956,17073884,17073901,17073881,17153202,17073916,17073945,17073883,17073943,17073909,17073950,17073942,17073906,17073886,17073910,17073882,17073941,17073891,17073929,17073928,17073903,17073912,17073930,17073898,17073899,17073954}'::integer[])) 
Filter: ((kind)::text = 'locality'::text) 
Rows Removed by Filter: 2037 
Heap Blocks: exact=17106 
-> BitmapAnd (cost=1418.04..1418.04 rows=29 width=0) (actual time=681.154..681.154 rows=0 loops=1) 
    -> Bitmap Index Scan on is_owner_index (cost=0.00..544.24 rows=29309 width=0) (actual time=5.493..5.493 rows=29201 loops=1) 
      Index Cond: (is_owner = 1) 
    -> Bitmap Index Scan on path_array_idx (cost=0.00..873.54 rows=739 width=0) (actual time=667.888..667.888 rows=607440 loops=1) 
      Index Cond: (path_array && '{17073888,17073984,17073885,17073905,17073958,17073927,17073908,17073952,17073948,17073947,17073917,17073944,17073919,17073922,17073914,17073937,17073895,17073904,17073911,17073949,17073938,17073957,17073900,17073915,17073936,17073887,17073933,17073939,17073956,17073884,17073901,17073881,17153202,17073916,17073945,17073883,17073943,17073909,17073950,17073942,17073906,17073886,17073910,17073882,17073941,17073891,17073929,17073928,17073903,17073912,17073930,17073898,17073899,17073954}'::integer[]) 
Planning time: 0.212 ms 
Execution time: 727.370 ms

上面的查詢耗時約700毫秒，我相信這是非常緩慢的。我是對的還是我要求太高？

來源

2016-11-09 bbrodriges

根據解釋計劃，查詢只需要700ms，而不是1.4秒 –

這是網絡延遲問題。修復它並增加了可能的解決方案 – bbrodriges

對我來說看起來很不錯 - afaiac，繼續並作爲回答發佈。 – shaunc

我已經在path_array和is_owner字段上創建了複雜索引。

CREATE INDEX path_array_owner_idx ON geo USING gin (path_array gin__int_ops) WHERE is_owner = 1 

------------------------------------------------------------------------------------- 
    Bitmap Heap Scan on geo (cost=436.04..550.99 rows=8 width=4) (actual time=30.292..68.778 rows=20984 loops=1) 
    Recheck Cond: ((path_array && '{17073888,17073984,17073885,17073905,17073958,17073927,17073908,17073952,17073948,17073947,17073917,17073944,17073919,17073922,17073914,17073937,17073895,17073904,17073911,17073949,17073938,17073957,17073900,17073915,17073936,17073887,17073933,17073939,17073956,17073884,17073901,17073881,17153202,17073916,17073945,17073883,17073943,17073909,17073950,17073942,17073906,17073886,17073910,17073882,17073941,17073891,17073929,17073928,17073903,17073912,17073930,17073898,17073899,17073954}'::integer[]) AND (is_owner = 1)) 
    Filter: ((kind)::text = 'locality'::text) 
    Rows Removed by Filter: 2037 
    Heap Blocks: exact=17106 
    -> Bitmap Index Scan on path_array_owner_idx (cost=0.00..436.04 rows=29 width=0) (actual time=25.923..25.923 rows=23021 loops=1) 
     Index Cond: (path_array && '{17073888,17073984,17073885,17073905,17073958,17073927,17073908,17073952,17073948,17073947,17073917,17073944,17073919,17073922,17073914,17073937,17073895,17073904,17073911,17073949,17073938,17073957,17073900,17073915,17073936,17073887,17073933,17073939,17073956,17073884,17073901,17073881,17153202,17073916,17073945,17073883,17073943,17073909,17073950,17073942,17073906,17073886,17073910,17073882,17073941,17073891,17073929,17073928,17073903,17073912,17073930,17073898,17073899,17073954}'::integer[]) 
Planning time: 0.219 ms 
Execution time: 72.956 ms

現在上面的查詢花了70毫秒，這很好。

來源

2017-10-11 08:44:05 bbrodriges

性能後代的搜索使用的Postgres intarray場

回答

相關問題