PostgreSQL的IN操作符的性能：列表VS子查询

对于〜700的ID列表查询的性能比通过返回的700个ID的子查询慢了20倍。它应该是相反的。PostgreSQL的IN操作符的性能：列表VS子查询

例如（第一查询需要400毫秒下，后来的9600毫秒）

select date_trunc('month', day) as month, sum(total) 
from table_x 
where y_id in (select id from table_y where prop = 'xyz') 
and day between '2015-11-05' and '2016-11-04' 
group by month

是快20倍我的机器上不是直接传递数组：

select date_trunc('month', day) as month, sum(total) 
from table_x 
where y_id in (1625, 1871, ..., 1640, 1643, 13291, 1458, 13304, 1407, 1765) 
and day between '2015-11-05' and '2016-11-04' 
group by month

任何想法可能是什么问题或如何优化和获得相同的表现？

来源

2016-11-05 Radu Gancea

有多大是数组？另外，为什么第一个查询不是写成简单的JOIN？您是否尝试使用'EXPLAIN'来查看查询引擎是否将其重写为JOIN？ – Kevin

'其中y_id =任何（阵列[1625，1871，...，1640，1643，13291，1458，13304，1407，1765]）' –

所不同的是一个简单的过滤器VS散列连接：

explain analyze 
select i 
from t 
where i in (500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600); 
               QUERY PLAN                                                       
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
Seq Scan on t (cost=0.00..140675.00 rows=101 width=4) (actual time=0.648..1074.567 rows=101 loops=1) 
    Filter: (i = ANY ('{500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600}'::integer[])) 
    Rows Removed by Filter: 999899 
Planning time: 0.170 ms 
Execution time: 1074.624 ms 

explain analyze 
select i 
from t 
where i in (select i from r); 
                QUERY PLAN              
------------------------------------------------------------------------------------------------------------------- 
Hash Semi Join (cost=3.27..17054.40 rows=101 width=4) (actual time=0.382..240.389 rows=101 loops=1) 
    Hash Cond: (t.i = r.i) 
    -> Seq Scan on t (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.030..117.193 rows=1000000 loops=1) 
    -> Hash (cost=2.01..2.01 rows=101 width=4) (actual time=0.074..0.074 rows=101 loops=1) 
     Buckets: 1024 Batches: 1 Memory Usage: 12kB 
     -> Seq Scan on r (cost=0.00..2.01 rows=101 width=4) (actual time=0.010..0.035 rows=101 loops=1) 
Planning time: 0.245 ms 
Execution time: 240.448 ms

要具有相同的性能加入数组：

explain analyze 
select i 
from 
    t 
    inner join 
    unnest(
     array[500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600]::int[] 
    ) u (i) using (i) 
; 
                 QUERY PLAN              
----------------------------------------------------------------------------------------------------------------------- 
Hash Join (cost=2.25..18178.25 rows=100 width=4) (actual time=0.267..243.768 rows=101 loops=1) 
    Hash Cond: (t.i = u.i) 
    -> Seq Scan on t (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.022..118.709 rows=1000000 loops=1) 
    -> Hash (cost=1.00..1.00 rows=100 width=4) (actual time=0.063..0.063 rows=101 loops=1) 
     Buckets: 1024 Batches: 1 Memory Usage: 12kB 
     -> Function Scan on unnest u (cost=0.00..1.00 rows=100 width=4) (actual time=0.028..0.041 rows=101 loops=1) 
Planning time: 0.172 ms 
Execution time: 243.816 ms

或者使用values语法：

explain analyze 
select i 
from t 
where i = any (values (500),(501),(502),(503),(504),(505),(506),(507),(508),(509),(510),(511),(512),(513),(514),(515),(516),(517),(518),(519),(520),(521),(522),(523),(524),(525),(526),(527),(528),(529),(530),(531),(532),(533),(534),(535),(536),(537),(538),(539),(540),(541),(542),(543),(544),(545),(546),(547),(548),(549),(550),(551),(552),(553),(554),(555),(556),(557),(558),(559),(560),(561),(562),(563),(564),(565),(566),(567),(568),(569),(570),(571),(572),(573),(574),(575),(576),(577),(578),(579),(580),(581),(582),(583),(584),(585),(586),(587),(588),(589),(590),(591),(592),(593),(594),(595),(596),(597),(598),(599),(600)) 
; 
                 QUERY PLAN              
----------------------------------------------------------------------------------------------------------------------- 
Hash Semi Join (cost=2.53..17053.65 rows=101 width=4) (actual time=0.279..239.888 rows=101 loops=1) 
    Hash Cond: (t.i = "*VALUES*".column1) 
    -> Seq Scan on t (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.022..117.199 rows=1000000 loops=1) 
    -> Hash (cost=1.26..1.26 rows=101 width=4) (actual time=0.059..0.059 rows=101 loops=1) 
     Buckets: 1024 Batches: 1 Memory Usage: 12kB 
     -> Values Scan on "*VALUES*" (cost=0.00..1.26 rows=101 width=4) (actual time=0.002..0.027 rows=101 loops=1) 
Planning time: 0.242 ms 
Execution time: 239.933 ms

来源

2017-02-16 11:51:17

尝试临界线改变为这样：

where y_id = any (values (1625, 1871, ..., 1640, 1643, 13291, 1458, 13304, 1407, 1765))

来源

2016-11-05 21:39:19 NiVeR

PostgreSQL的IN操作符的性能：列表VS子查询

回答

相关问题