问题描述
这是我几天前发布的后续问题。 In PostgreSQL what does hashed subplan mean?
下面是我的问题。
我想知道优化器如何重写查询以及如何读取Postgresql中的执行计划。这是示例代码。
DROP TABLE ords;
CREATE TABLE ords (
ORD_ID INT NOT NULL,ORD_PROD_ID VARCHAR(2) NOT NULL,ETC_CONTENT VARCHAR(100));
ALTER TABLE ords ADD CONSTRAINT ords_PK PRIMARY KEY(ORD_ID);
CREATE INDEX ords_X01 ON ords(ORD_PROD_ID);
INSERT INTO ords
SELECT i,chr(64+case when i <= 10 then i else 26 end),rpad('x',100,'x')
FROM generate_series(1,10000) a(i);
SELECT COUNT(*) FROM ords WHERE ORD_PROD_ID IN ('A','B','C');
DROP TABLE delivery;
CREATE TABLE delivery (
ORD_ID INT NOT NULL,VEHICLE_ID VARCHAR(2) NOT NULL,ETC_REMARKS VARCHAR(100));
ALTER TABLE delivery ADD CONSTRAINT delivery_PK primary key (ORD_ID,VEHICLE_ID);
CREATE INDEX delivery_X01 ON delivery(VEHICLE_ID);
INSERT INTO delivery
SELECT i,chr(88 + case when i <= 10 then mod(i,2) else 2 end),10000) a(i);
analyze ords;
analyze delivery;
This is the sql I am interested in.
SELECT *
FROM ords a
WHERE ( EXISTS (SELECT 1
FROM delivery b
WHERE a.ORD_ID = b.ORD_ID
AND b.VEHICLE_ID IN ('X','Y')
)
OR a.ORD_PROD_ID IN ('A','C')
);
Here is the execution plan
| Seq Scan on portal.ords a (actual time=0.038..2.027 rows=10 loops=1) |
| Output: a.ord_id,a.ord_prod_id,a.etc_content |
| Filter: ((alternatives: SubPlan 1 or hashed SubPlan 2) OR ((a.ord_prod_id)::text = ANY ('{A,B,C}'::text[]))) |
| Rows Removed by Filter: 9990 |
| Buffers: shared hit=181 |
| SubPlan 1 |
| -> Index Only Scan using delivery_pk on portal.delivery b (never executed) |
| Index Cond: (b.ord_id = a.ord_id) |
| Filter: ((b.vehicle_id)::text = ANY ('{X,Y}'::text[])) |
| Heap Fetches: 0 |
| SubPlan 2 |
| -> Index Scan using delivery_x01 on portal.delivery b_1 (actual time=0.023..0.025 rows=10 loops=1) |
| Output: b_1.ord_id |
| Index Cond: ((b_1.vehicle_id)::text = ANY ('{X,Y}'::text[])) |
| Buffers: shared hit=8 |
| Planning: |
| Buffers: shared hit=78 |
| Planning Time: 0.302 ms |
| Execution Time: 2.121 ms
我不知道优化器如何转换 sql。优化器重写的最终 sql 是什么?我上面的sql中只有一个EXISTS子查询,为什么有两个子计划? “散列子计划 2”是什么意思?如果有人与我分享一点知识,我将不胜感激。
以下是 Laurenz Albe 的回答。
您有一种误解,认为优化器会重写 sql 语句。事实并非如此。重写查询是查询重写器的工作,例如用它们的定义替换视图。优化器提出了一系列执行步骤来计算结果。它生成一个计划,而不是一个 sql 语句。 优化器计划两种选择:要么为找到的每一行执行子计划 1,要么执行子计划 2 一次(注意它与 a 无关),根据结果构建一个哈希表并为在 a 中找到的每一行探测该哈希。 在执行时,Postgresql 决定使用后一种策略,这就是子计划 1 永远不会执行的原因。
Laurenz 的回答启发了我。 但是,我想知道查询重写器重写的最终查询是什么。 这是我认为查询重写器会做的重写查询。 我对吗? 作为这个问题的读者,您认为最终重写的查询会是什么?
(
SELECT *
FROM ords a
WHERE EXISTS (SELECT 1
FROM delivery b
WHERE a.ORD_ID = B.ORD_ID
AND b.VEHICLE_ID IN ('X','Y')
OFFSET 0 --> the optimizer prevented subquery collapse.
)
*alternative OR*
SELECT a.*
FROM ords a *(Semi Hash Join)* delivery b --> the optimizer used b as an build input
WHERE a.ORD_ID = b.ORD_ID
AND b.VEHICLE_ID IN ('X','Y') --> the optimzer used the delivery_x01 index.
)
*filtered OR*
SELECT *
FROM ords a
WHERE a.ORD_PROD_ID IN ('A','C') --> the optimizer cannot use the ords_x01 index due to the query transformation
解决方法
没有。子计划不是由重写器生成,而是由优化器生成。一旦优化器接管,您就永远离开了 SQL 领域。它生成的过程执行步骤无法用声明性 SQL 语言表示。