PostgreSQL在类似服务器上的不同查询计划

Question

在具有相同数据库的类似Amazon RDS PostgreSQL服务器版本9.6.11上，我获得了一个SQL查询的不同执行计划。

我试图重新创建索引并运行ANALYZE和VACUUM。什么都没有帮助我。

我的查询：

SELECT "users_employee"."id",
       (
           SELECT U0."created"
           FROM "surveys_surveyrequest" U0
           WHERE (U0."confirmed" IS NULL
                  AND U0."skipped" IS NULL
                  AND U0."from_member_id" = ("users_employee"."id"))
           ORDER BY U0."created" ASC
           LIMIT 1) AS "earliest_request_date"
FROM "users_employee"
ORDER BY "users_employee"."id" ASC;

问题表信息：

 create table surveys_surveyrequest
(
    id integer default nextval('public.surveys_surveyrequest_id_seq'::regclass) not null
        constraint surveys_surveyrequest_pkey
            primary key,
    created timestamp with time zone not null,
    skipped timestamp with time zone,
    from_member_id integer
        constraint surveys_surveyreques_from_member_id_81f0e82e_fk_users_emp
            references users_employee
                deferrable initially deferred,
    confirmed timestamp with time zone
);

create index surveys_sur_confirm_48bfa6_idx
    on surveys_surveyrequest (confirmed);

create index surveys_sur_created_099976_idx
    on surveys_surveyrequest (created);


create index surveys_surveyrequest_70b76ad7
    on surveys_surveyrequest (from_member_id);

计划：A：

                                                                                    QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Only Scan using auth_user_pkey on users_employee  (cost=0.28..991903.69 rows=1478 width=12) (actual time=139.054..195486.465 rows=1478 loops=1)
   Heap Fetches: 51
   Buffers: shared hit=296637323
   SubPlan 1
     ->  Limit  (cost=0.42..671.07 rows=1 width=8) (actual time=132.258..132.259 rows=1 loops=1478)
           Buffers: shared hit=296637288
           ->  Index Scan using surveys_sur_created_099976_idx on surveys_surveyrequest u0  (cost=0.42..24143.63 rows=36 width=8) (actual time=132.256..132.256 rows=1 loops=1478)
                 Filter: ((confirmed IS NULL) AND (skipped IS NULL) AND (from_member_id = users_employee.id))
                 Rows Removed by Filter: 405780
                 Buffers: shared hit=296637288
 Planning time: 0.188 ms
 Execution time: 195487.356 ms
(12 rows)

B：

                                                                                  QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Only Scan using auth_user_pkey on users_employee  (cost=0.28..886476.74 rows=1578 width=12) (actual time=0.977..1043.414 rows=1578 loops=1)
   Heap Fetches: 0
   Buffers: shared hit=98270 read=8
   SubPlan 1
     ->  Limit  (cost=561.74..561.74 rows=1 width=8) (actual time=0.658..0.659 rows=1 loops=1578)
           Buffers: shared hit=98266 read=5
           ->  Sort  (cost=561.74..561.79 rows=22 width=8) (actual time=0.658..0.658 rows=1 loops=1578)
                 Sort Key: u0.created
                 Sort Method: quicksort  Memory: 25kB
                 Buffers: shared hit=98266 read=5
                 ->  Bitmap Heap Scan on surveys_surveyrequest u0  (cost=474.19..561.63 rows=22 width=8) (actual time=0.646..0.652 rows=13 loops=1578)
                       Recheck Cond: ((from_member_id = users_employee.id) AND (confirmed IS NULL))
                       Filter: (skipped IS NULL)
                       Rows Removed by Filter: 3
                       Heap Blocks: exact=9707
                       Buffers: shared hit=98266 read=5
                       ->  BitmapAnd  (cost=474.19..474.19 rows=23 width=0) (actual time=0.641..0.641 rows=0 loops=1578)
                             Buffers: shared hit=88562 read=2
                             ->  Bitmap Index Scan on surveys_surveyrequest_70b76ad7  (cost=0.00..11.29 rows=382 width=0) (actual time=0.023..0.023 rows=258 loops=1578)
                                   Index Cond: (from_member_id = users_employee.id)
                                   Buffers: shared hit=5847 read=2
                             ->  Bitmap Index Scan on surveys_sur_confirm_48bfa6_idx  (cost=0.00..462.64 rows=24829 width=0) (actual time=0.826..0.826 rows=24756 loops=1165)
                                   Index Cond: (confirmed IS NULL)
                                   Buffers: shared hit=82715
 Planning time: 0.234 ms
 Execution time: 1043.680 ms
(26 rows)

Time: 1044,547 ms (00:01,045)

我希望生成相同的查询计划，但这不会发生。可能是什么原因？如何用B计划实现执行？

Answer 1

请检查两台服务器上的配置是否相同，并且所有索引都存在且未标记为“无效”。

假设情况如此，差异可能是数据在两个数据库中的分布不同。请ANALYZE surveys_surveyrequest并在两个数据库上运行以下命令：

SELECT correlation
FROM pg_stats
WHERE tablename = 'surveys_surveyrequest'
  AND attname = 'created';

我的猜测是A上的值接近1或-1，B上接近0。

That would explain为什么PostgreSQL更喜欢在A上进行索引扫描。计划A的问题是PostgreSQL必须扫描比它所讨论的更多的索引行，可能是因为匹配条件的行都远远落后于索引。

我要说你应该简单地禁用surveys_sur_created_099976_idx上的索引扫描

DROP INDEX surveys_sur_created_099976_idx;

或（如果您需要用于其他目的的索引）使用

ORDER BY U0."created" + INTERVAL '0 seconds'