Question

我一直在努力弄清楚如何让查询规划在一段时间内变得更聪明一些，现在非常不成功。我已经和work_mem和朋友搞混了，运行vacumm analyze很多，并尝试用order by改变查询。我已经包含了3次使用不同偏移量的同一查询。我的印象是这个查询的效果不尽如人意。有什么想法吗？

万一它不会跳出来 - 以下查询之间的唯一变化是offset

bloomapi=# explain analyze SELECT * FROM npis WHERE provider_last_name_legal_name = 'THOMPSON' offset 250 limit 10;
                                                                             QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=965.13..998.97 rows=10 width=2589) (actual time=568.458..577.507 rows=10 loops=1)
   ->  Bitmap Heap Scan on npis  (cost=119.15..20382.11 rows=5988 width=2589) (actual time=58.140..577.027 rows=260 loops=1)
         Recheck Cond: ((provider_last_name_legal_name)::text = 'THOMPSON'::text)
         ->  Bitmap Index Scan on npis_temp_provider_last_name_legal_name_idx1  (cost=0.00..117.65 rows=5988 width=0) (actual time=36.819..36.819 rows=5423 loops=1)
               Index Cond: ((provider_last_name_legal_name)::text = 'THOMPSON'::text)
 Total runtime: 578.301 ms
(6 rows)

bloomapi=# explain analyze SELECT * FROM npis WHERE provider_last_name_legal_name = 'THOMPSON' offset 100 limit 10;
                                                                             QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=395.81..435.40 rows=10 width=2589) (actual time=0.397..0.440 rows=10 loops=1)
   ->  Index Scan using npis_temp_provider_last_name_legal_name_idx1 on npis  (cost=0.00..23701.38 rows=5988 width=2589) (actual time=0.063..0.293 rows=110 loops=1)
         Index Cond: ((provider_last_name_legal_name)::text = 'THOMPSON'::text)
 Total runtime: 0.952 ms
(4 rows)

bloomapi=# explain analyze SELECT * FROM npis WHERE provider_last_name_legal_name = 'THOMPSON' offset 4100 limit 10;
                                                                            QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=13993.25..14027.09 rows=10 width=2589) (actual time=9356.723..9400.021 rows=10 loops=1)
   ->  Bitmap Heap Scan on npis  (cost=119.15..20382.11 rows=5988 width=2589) (actual time=2.968..9393.327 rows=4110 loops=1)
         Recheck Cond: ((provider_last_name_legal_name)::text = 'THOMPSON'::text)
         ->  Bitmap Index Scan on npis_temp_provider_last_name_legal_name_idx1  (cost=0.00..117.65 rows=5988 width=0) (actual time=1.943..1.943 rows=5423 loops=1)
               Index Cond: ((provider_last_name_legal_name)::text = 'THOMPSON'::text)
 Total runtime: 9400.426 ms
(6 rows)

一些相关说明：

我在运行第一个查询之前清除了系统上的共享内存，因此第一个查询的某些实际时间可能受到索引加载的影响
数据宽且稀疏 - 329列，其中许多是空字符变化（30ish）
数据实际上是只读的 - 每周更新一次15k行。
当ubuntu ppa附带默认数据库设置时，这些查询的性能实际上更高（我目前没有这些查询计划，但如果没有明显的跳出来，可能会深入研究它们除此以外）。已从默认值更改的参数：shared_buffers = 256MB，effective_cache_size = 512MB，checkpoint_segments = 64，checkpoint_completion_target = 0.9，default_statistics_target = 500
表格本身大约有4百万行/1.29GB的实际数据，provider_last_name_legal_name是btree索引的 - 索引的大小是95mb。大约3/4的行在此列中具有非空值，整个表具有488k个不同的值

Answer 1

我有根据的猜测是，大额抵消正在触发这些计划。即使您将结果限制为十行，PostgreSQL也必须考虑前面的所有行。我怀疑当您删除offset时（例如在第一个查询中使用limit 260），您会看到类似的运行时。

您可以使用configuration parameters禁用某些计划类型，直到查询共享相似的计划。这可以帮助您了解为什么一个计划比另一个更好。

set enable_bitmapscan = false;

一致地获取特定查询的postgres查询计划以使用索引而不是扫描

1 个答案: