Postgres选择查询进行顺序扫描，而不是在桌子上使用1800万行的索引扫描

Question

我有一个Postgres表，该表有近1800万行，我试图运行此查询，

select * from answer where submission_id = 5 and deleted_at is NULL;

列cummission_id的表上有一个部分索引。这是用于创建索引的命令，

CREATE INDEX answer_submission_id ON answer USING btree (submission_id) WHERE (deleted_at IS NULL)

这是上述选择查询的解释分析

Gather  (cost=1000.00..3130124.70 rows=834 width=377) (actual time=7607.568..7610.130 rows=2 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  Buffers: shared hit=2144966 read=3
  I/O Timings: read=6.169
  ->  Parallel Seq Scan on answer  (cost=0.00..3129041.30 rows=348 width=377) (actual time=6501.951..7604.623 rows=1 loops=3)
        Filter: ((deleted_at IS NULL) AND (submission_id = 5))
        Rows Removed by Filter: 62213625
        Buffers: shared hit=2144966 read=3
        I/O Timings: read=6.169
Planning Time: 0.117 ms
Execution Time: 7610.154 ms

，理想情况下应该选择答案_submission_id索引。但是Postgres正在进行顺序扫描。

任何帮助真的很感激

Answer 1

执行计划表明我们在估计的读取行与实际读取行之间存在偏差。

PostgreSQL Optimizer是一个基于成本的优化器（CBO）查询，将通过执行计划中最小的成本执行。

因此，错误的统计数据可能会选择不良的执行计划。

有一个链接来表示错误的统计信息，导致查询缓慢。
为什么Postgres中的不良行估计很慢？ >

首先，我将使用此查询搜索last_analyze＆amp; last_vacuum上次。

SELECT
  schemaname, relname,
  last_vacuum, last_autovacuum,
  vacuum_count, autovacuum_count,
  last_analyze,last_autoanalyze
FROM pg_stat_user_tables
where relname = 'tablename';

如果您的统计数据错了，我们可以使用分析“ TaberName”来帮助我们从表中收集新统计信息， 分析 扫描速度取决于表尺寸。

对于大表格，分析是随机的表内容样本，而不是检查每个行。这允许在少量时间内分析非常大的表。但是，请注意，即使实际表内容不更改，统计数据仅近似，并且每次进行分析时都会稍微改变。这可能会导致策划者所显示的估计成本的微小变化。在极少数情况下，这种非确定性将导致计划者在进行分析后更改的查询计划的选择。为避免这种情况，请提高分析收集的统计量，如下所述。

当我们更新和delete数据将创建可能存在于堆或索引中的死元元组，但我们无法查询，vacuum可以帮助我们收回死亡元素所占据的存储空间。