postgresql – 为什么真空分析改变查询计划而分析没有？

概述我想在Postgres中利用仅索引扫描的强大功能,并尝试使用一个表： CREATE TABLE dest.contexts( id integer NOT NULL, phrase_id integer NOT NULL, lang character varying(5) NOT NULL, ranking_value double precision, index_min 我想在Postgres中利用仅索引扫描的强大功能,并尝试使用一个表：

CREATE table dest.contexts(  ID integer NOT NulL,phrase_ID integer NOT NulL,lang character varying(5) NOT NulL,ranking_value double precision,index_min integer,index_max integer,case_sensitive boolean,is_enabled boolean,is_to_sync boolean NOT NulL DEFAulT true);insert into dest.contexts select * from source.contexts;alter table dest.contexts  add constraint pk_contexts primary key (ID,phrase_ID,lang); CREATE INDEX IDx_contexts_  ON dest.contexts  USING btree  (ID,is_enabled,lang,ranking_value,index_min,index_max,case_sensitive);

索引涵盖了我想在下一个查询中使用的所有列：

explain analyzeselect ranking_value,case_sensitivefrom dest.contextswhere ID = 456 and is_enabled

我在创建后立即检查计划：

Bitmap Heap Scan on contexts  (cost=4.41..31.46 rows=12 wIDth=17) (actual time=0.045..0.045 rows=0 loops=1)  Recheck Cond: (ID = 456)  Filter: is_enabled  ->  Bitmap Index Scan on IDx_contexts_  (cost=0.00..4.40 rows=12 wIDth=0) (actual time=0.038..0.038 rows=0 loops=1)        Index Cond: ((ID = 456) AND (is_enabled = true))Planning time: 0.631 msExecution time: 0.093 ms

这很奇怪,但还行……

几秒钟后它变成了另一个(autovacuum？)

Index Scan using pk_contexts on contexts  (cost=0.28..17.93 rows=6 wIDth=17) (actual time=0.027..0.027 rows=0 loops=1)  Index Cond: (ID = 456)  Filter: is_enabledPlanning time: 0.185 msExecution time: 0.070 ms

我尝试强制它使用仅索引扫描：

analyze dest.contexts

但它没有改变任何东西.然后我做

vacuum verbose analyze dest.contexts;INFO:  vacuuming "dest.contexts"INFO:  index "pk_contexts" Now contains 4845 row versions in 21 pagesDETAIL:  0 index row versions were removed.0 index pages have been deleted,0 are currently reusable.cpu 0.00s/0.00u sec elapsed 0.00 sec.INFO:  index "IDx_contexts_" Now contains 4845 row versions in 37 pagesDETAIL:  0 index row versions were removed.0 index pages have been deleted,0 are currently reusable.cpu 0.00s/0.00u sec elapsed 0.00 sec.INFO:  "contexts": found 0 removable,4845 nonremovable row versions in 41 out of 41 pagesDETAIL:  0 dead row versions cannot be removed yet.There were 0 unused item pointers.0 pages are entirely empty.cpu 0.00s/0.00u sec elapsed 0.00 sec.INFO:  analyzing "dest.contexts"INFO:  "contexts": scanned 41 of 41 pages,containing 4845 live rows and 0 dead rows; 4845 rows in sample,4845 estimated total rows

在这里,我终于得到了我想要的东西：

Index Only Scan using IDx_contexts_ on contexts  (cost=0.28..4.40 rows=6 wIDth=17) (actual time=0.014..0.014 rows=0 loops=1)  Index Cond: ((ID = 456) AND (is_enabled = true))  Filter: is_enabled  Heap Fetches: 0Planning time: 0.247 msExecution time: 0.052 ms

以下是问题：

>为什么不分析教它使用大的“全覆盖”指数？
>为什么真空分析会这样做？
>我的桌子从头开始用一个大插件填充.真空为什么要做任何事情？在我看来,那里没有任何真空.

Analyze负责收集统计数据,并分析对查询计划和计划成本的选择有影响.

索引不包含有关元组的可见性信息.因此,虽然select中的所有列都在索引中,但也会应用读取数据页和对结果集进行过滤.如果页面中显示所有元组,Postgres不需要额外的过滤 *** 作. Postgres使用可见性图(vm)来实现这一点.

真空使用并更新可见性图,同时回收死元组.因此,如果可能,vacuum会更改查询计划以使用仅索引扫描.

https://www.postgresql.org/docs/9.6/static/sql-vacuum.html

https://www.postgresql.org/docs/9.6/static/storage-vm.html

总结

以上是内存溢出为你收集整理的postgresql – 为什么真空分析改变查询计划而分析没有？全部内容，希望文章能够帮你解决postgresql – 为什么真空分析改变查询计划而分析没有？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。