第二个几乎相同的子查询需要更长的时间

时间:2016-05-10 18:45:54

标签: sql postgresql

我在路由数据库上执行一个SQL查询,其中包含两个几乎相同的子查询,大约有18个条目:

EXPLAIN (ANALYZE, BUFFERS, VERBOSE) SELECT source.source, target.target FROM
    (SELECT source FROM at_2po_4pgr WHERE osm_source_id=380253639 LIMIT 1) as source,
    (SELECT target FROM at_2po_4pgr WHERE osm_target_id=373850046 LIMIT 1) as target

Explain分析返回以下内容:

Nested Loop  (cost=0.00..491634.63 rows=1 width=8) (actual time=6437.767..6437.768 rows=1 loops=1)
   Output: at_2po_4pgr.source, at_2po_4pgr_1.target
   Buffers: shared hit=6136 read=1684402
   ->  Limit  (cost=0.00..215090.14 rows=1 width=4) (actual time=6437.740..6437.740 rows=1 loops=1)
         Output: at_2po_4pgr.source
         Buffers: shared hit=6132 read=1684402
         ->  Seq Scan on public.at_2po_4pgr  (cost=0.00..1935811.25 rows=9 width=4) (actual time=6437.738..6437.738 rows=1 loops=1)
               Output: at_2po_4pgr.source
               Filter: (at_2po_4pgr.osm_source_id = 380253639)
               Rows Removed by Filter: 17052688
               Buffers: shared hit=6132 read=1684402
   ->  Limit  (cost=0.00..276544.46 rows=1 width=4) (actual time=0.020..0.020 rows=1 loops=1)
         Output: at_2po_4pgr_1.target
         Buffers: shared hit=4
         ->  Seq Scan on public.at_2po_4pgr at_2po_4pgr_1  (cost=0.00..1935811.25 rows=7 width=4) (actual time=0.020..0.020 rows=1 loops=1)
               Output: at_2po_4pgr_1.target
               Filter: (at_2po_4pgr_1.osm_target_id = 373850046)
               Rows Removed by Filter: 94
               Buffers: shared hit=4
 Planning time: 0.109 ms
 Execution time: 6437.887 ms

在这种情况下,第一个子查询需要大约6500毫秒,而第二个子查询只需要0.02毫秒!有时它是另一种方式,所以第二个查询是慢的。当我将查询作为单个查询运行时,它们会在10毫秒内返回。所以我假设没有足够的缓冲存储器来执行这两个查询,但是我已经大量增加了大部分默认值。

我目前的postgresql内存设置是:

# - Memory -

shared_buffers = 12GB                   # min 128kB
                                        # (change requires restart)
#huge_pages = try                       # on, off, or try
                                        # (change requires restart)
temp_buffers = 64MB                     # min 800kB
#max_prepared_transactions = 0          # zero disables the feature
                                        # (change requires restart)
# Note:  Increasing max_prepared_transactions costs ~600 bytes of shared memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
# It is not advisable to set max_prepared_transactions nonzero unless you
# actively intend to use prepared transactions.
work_mem = 256MB                                # min 64kB
maintenance_work_mem = 512MB            # min 1MB
#autovacuum_work_mem = -1               # min 1MB, or -1 to use maintenance_work_mem
#max_stack_depth = 2MB                  # min 100kB
dynamic_shared_memory_type = posix      # the default is the first option
                                        # supported by the operating system:
                                        #   posix
                                        #   sysv
                                        #   windows
                                        #   mmap
                                        # use none to disable dynamic shared memory

所以我完全不知道这些不同执行时间的原因。

1 个答案:

答案 0 :(得分:1)

不确定为什么你有不同的时间。我的猜测是第一次扫描表,第二次利用一些缓存,所以花费的时间更少。

尝试反转查询的顺序,看看你是否有类似的结果或时间的变化

EXPLAIN (ANALYZE, BUFFERS, VERBOSE) SELECT source.source, target.target FROM        
    (SELECT target FROM at_2po_4pgr WHERE osm_target_id=373850046 LIMIT 1) as target,
    (SELECT source FROM at_2po_4pgr WHERE osm_source_id=380253639 LIMIT 1) as source

BTW :您应该为target创建一个索引,为source创建一个索引。正如您在EXPLAIN上看到的那样,查询正在执行SEQ SCAN

编辑:看到EXPLAIN消息Rows Removed by Filter: 17052688 vs Rows Removed by Filter: 94后,搜索可能会出现targetlimit 1停止搜索看起来更快。尝试使用不同的ID值这是您应该创建一个索引的另一个原因。