使用EXPLAIN
PostgreSQL为每个收到的查询设计一个查询规划。选择正确的匹配查询结构和数据属性的规划对执行效率是至关重要要的，所以系统包含一个复杂的规划器来试图选择好的规划。你可以使用EXPLAIN命令查看查询规划器创建的任何查询。阅读查询规划是一门艺术，需要掌握一定的经验，本节试图涵盖一些基础知识。
以下的例子来自PostgreSQL 9.3开发版。
EXPLAIN基础
查询规划是以规划为节点的树形结构。树的最底节点是扫描节点：他返回表中的原数据行。
不同的表有不同的扫描节点类型：顺序扫描，索引扫描和位图索引扫描。
也有非表列源，如VALUES子句并设置FROM返回，他们有自己的扫描类型。
如果查询需要关联，聚合，排序或其他操作，会在扫描节点之上增加节点执行这些操作。通常有不只一种可能的方式做这些操作，所以可能出现不同的节点类型。
EXPLAIN的输出是每个树节点显示一行，内容是基本节点类型和执行节点的消耗评估。可能会楚翔其他行，从汇总行节点缩进显示节点的其他属性。第一行（最上节点的汇总行）是评估执行计划的总消耗，这个值越小越好。
下面是一个简单的例子：
EXPLAIN SELECT * FROM tenk1;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)
因为这个查询没有WHERE子句，所以必须扫描表中的所有行，所以规划器选择使用简单的顺序扫描规划。括号中的数字从左到右依次是：
- 评估开始消耗。这是可以开始输出前的时间，比如排序节点的排序的时间。
- 评估总消耗。假设查询从执行到结束的时间。有时父节点可能停止这个过程，比如LIMIT子句。
- 评估查询节点的输出行数，假设该节点执行结束。
- 评估查询节点的输出行的平均字节数。
这个消耗的计算依赖于规划器的设置参数，这里的例子都是在默认参数下运行。
需要知道的是：上级节点的消耗包括其子节点的消耗。这个消耗值只反映规划器关心的内容，一般这个消耗不包括将数据传输到客户端的时间。
评估的行数不是执行和扫描查询节点的数量，而是节点返回的数量。它通常会少于扫描数量，因为有WHERE条件会过滤掉一些数据。理想情况顶级行数评估近似于实际返回的数量
回到刚才的例子，表tenk1有10000条数据分布在358个磁盘页，评估时间是（磁盘页*seq_page_cost）+（扫描行*cpu_tuple_cost）。默认seq_page_cost是1.0，cpu_tuple_cost是0.01，所以评估值是(358 * 1.0) + (10000 * 0.01) = 458
现在我们将查询加上WHERE子句：
EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;
QUERY PLAN
------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..483.00 rows=7001 width=244)
Filter: (unique1 < 7000)
查询节点增加了“filter”条件。这意味着查询节点为扫描的每一行数据增加条件检查，只输入符合条件数据。评估的输出记录数因为where子句变少了，但是扫描的数据还是10000条，所以消耗没有减少，反而增加了一点cup的计算时间。
这个查询实际输出的记录数是7000，但是评估是个近似值，多次运行可能略有差别，这中情况可以通过ANALYZE命令改善。
现在再修改一下条件
EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;
QUERY PLAN
------------------------------------------------------------------------------
Bitmap Heap Scan on tenk1 (cost=5.07..229.20 rows=101 width=244)
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
Index Cond: (unique1 < 100)
查询规划器决定使用两步规划：首先子查询节点查看索引找到符合条件的记录索引，然后外层查询节点将这些记录从表中提取出来。分别提取数据的成本要高于顺序读取，但因为不需要读取所有磁盘页，所以总消耗比较小。（其中Bitmap是系统排序的一种机制）
现在，增加另一个查询条件：
EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND stringu1 = 'xxx';
QUERY PLAN
------------------------------------------------------------------------------
Bitmap Heap Scan on tenk1 (cost=5.04..229.43 rows=1 width=244)
Recheck Cond: (unique1 < 100)
Filter: (stringu1 = 'xxx'::name)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
Index Cond: (unique1 < 100)
增加的条件stringu1='xxx'减少了输出记录数的评估，但没有减少时间消耗，应为系统还是要查询相同数量的记录。请注意stringu1不是索引条件。
如果在不同的字段上有独立的索引，规划器可能选择使用AND或者OR组合索引：
EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000;
QUERY PLAN
-------------------------------------------------------------------------------------
Bitmap Heap Scan on tenk1 (cost=25.08..60.21 rows=10 width=244)
Recheck Cond: ((unique1 < 100) AND (unique2 > 9000))
-> BitmapAnd (cost=25.08..25.08 rows=10 width=0)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
Index Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique2 (cost=0.00..19.78 rows=999 width=0)
Index Cond: (unique2 > 9000)
这个查询条件的两个字段都有索引，索引不需要filre。
下面我们来看看LIMIT的影响：
EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000 LIMIT 2;
QUERY PLAN
-------------------------------------------------------------------------------------
Limit (cost=0.29..14.48 rows=2 width=244)
-> Index Scan using tenk1_unique2 on tenk1 (cost=0.29..71.27 rows=10 width=244)
Index Cond: (unique2 > 9000)
Filter: (unique1 < 100)
这条查询的where条件和上面的一样，只是增加了LIMIT，所以不是所有数据都需要返回，规划器改变了规划。在索引扫描节点总消耗和返回记录数是运行玩查询之后的数值，但Limit节点预期时间消耗是15，所以总时间消耗是15.增加LIMIT会使启动时间小幅增加（0.25->0.29）。
来看一下通过索引字段的表连接：
EXPLAIN SELECT *
FROM tenk1 t1, tenk2 t2
WHERE t1.unique1 < 10 AND t1.unique2 = t2.unique2;
QUERY PLAN
--------------------------------------------------------------------------------------
Nested Loop (cost=4.65..118.62 rows=10 width=488)
-> Bitmap Heap Scan on tenk1 t1 (cost=4.36..39.47 rows=10 width=244)
Recheck Cond: (unique1 < 10)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..4.36 rows=10 width=0)
Index Cond: (unique1 < 10)
-> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..7.91 rows=1 width=244)
Index Cond: (unique2 = t1.unique2)
这个规划中有一个内连接的节点，它有两个子节点。节点摘要行的缩进反映了规划树的结构。最外层是一个连接节点，子节点是一个Bitmap扫描。外部节点位图扫描的消耗和记录数如同我们使用SELECT...WHERE unique1 < 10，因为这时t1.unique2 = t2.unique2还不相关。接下来为每一个从外部节点得到的记录运行内部查询节点。这里外部节点得到的数据的t1.unique2值是可用的，所以我们得到的计划和SELECT...WHEREt2.unique2=constant的情况类似。（考虑到缓存的因素评估的消耗可能要小一些）
外部节点的消耗加上循环内部节点的消耗（39.47+10*7.91）再加一点CPU时间就得到规划的总消耗。
再看一个例子：
EXPLAIN SELECT *
FROM tenk1 t1, tenk2 t2
WHERE t1.unique1 < 10 AND t2.unique2 < 10 AND t1.hundred < t2.hundred;
QUERY PLAN
---------------------------------------------------------------------------------------------
Nested Loop (cost=4.65..49.46 rows=33 width=488)
Join Filter: (t1.hundred < t2.hundred)
-> Bitmap Heap Scan on tenk1 t1 (cost=4.36..39.47 rows=10 width=244)
Recheck Cond: (unique1 < 10)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..4.36 rows=10 width=0)
Index Cond: (unique1 < 10)
-> Materialize (cost=0.29..8.51 rows=10 width=244)
-> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..8.46 rows=10 width=244)
Index Cond: (unique2 < 10)
条件t1.hundred<t2.hundred不在tenk2_unique2索引中，所以这个条件出现在连接节点中。这将减少连接节点的评估输出记录数，但不会改变子节点的扫描数。
注意这次规划器选择使用Meaterialize节点，将条件加入内部节点，这以为着内部节点的索引扫描只做一次，即使嵌套循环需要读取这些数据10次，Meterialize节点将数据保存在内存中，每次循环都从内存中读取数据。
如果我们稍微改变一下查询，会看到完全不同的规划：
EXPLAIN SELECT *
FROM tenk1 t1, tenk2 t2
WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
QUERY PLAN
------------------------------------------------------------------------------------------
Hash Join (cost=230.47..713.98 rows=101 width=488)
Hash Cond: (t2.unique2 = t1.unique2)
-> Seq Scan on tenk2 t2 (cost=0.00..445.00 rows=10000 width=244)
-> Hash (cost=229.20..229.20 rows=101 width=244)
-> Bitmap Heap Scan on tenk1 t1 (cost=5.07..229.20 rows=101 width=244)
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
Index Cond: (unique1 < 100)
这里规划器选择使用hash join，将一个表的数据存入内存中的哈希表，然后扫描另一个表并和哈希表中的每一条数据进行匹配。
注意缩进反应的规划结构。在tenk1表上的bitmap扫描结果作为Hash节点的输入建立哈希表。然后Hash Join节点读取外层子节点的数据，再循环检索哈希表的数据。
另一个可能的连接类型是merge join：
EXPLAIN SELECT *
FROM tenk1 t1, onek t2
WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
QUERY PLAN
------------------------------------------------------------------------------------------
Merge Join (cost=198.11..268.19 rows=10 width=488)
Merge Cond: (t1.unique2 = t2.unique2)
-> Index Scan using tenk1_unique2 on tenk1 t1 (cost=0.29..656.28 rows=101 width=244)
Filter: (unique1 < 100)
-> Sort (cost=197.83..200.33 rows=1000 width=244)
Sort Key: t2.unique2
-> Seq Scan on onek t2 (cost=0.00..148.00 rows=1000 width=244)
Merge Join需要已经排序的输入数据。在这个规划中按正确顺序索引扫描tenk1的数据，但是对onek表执行排序和顺序扫描，因为需要在这个表中查询多条数据。因为索引扫描需要访问不连续的磁盘，所以索引扫描多条数据时会频繁使用排序顺序扫描（Sequential-scan-and-sort）。有一种方法可以看到不同的规划，就是强制规划器忽略任何策略。例如，如果我们不相信排序顺序扫描（sequential-scan-and-sort）是最好的办法，我们可以尝试这样的做法：
SET enable_sort = off;
EXPLAIN SELECT *
FROM tenk1 t1, onek t2
WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
QUERY PLAN
------------------------------------------------------------------------------------------
Merge Join (cost=0.56..292.65 rows=10 width=488)
Merge Cond: (t1.unique2 = t2.unique2)
-> Index Scan using tenk1_unique2 on tenk1 t1 (cost=0.29..656.28 rows=101 width=244)
Filter: (unique1 < 100)
-> Index Scan using onek_unique2 on onek t2 (cost=0.28..224.79 rows=1000 width=244)
显示测结果表明，规划器认为索引扫描比排序顺序扫描消耗高12%。当然下一个问题就是规划器的评估为什么是正确的。我们可以通过EXPLAIN ANALYZE进行考察。EXPLAIN ANALYZE
通过EXPLAIN ANALYZE可以检查规划器评估的准确性。使用ANALYZE选项，EXPLAIN实际运行查询，显示真实的返回记录数和运行每个规划节点的时间，例如我们可以得到下面的结果：
EXPLAIN ANALYZE SELECT *
FROM tenk1 t1, tenk2 t2
WHERE t1.unique1 < 10 AND t1.unique2 = t2.unique2;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
Nested Loop (cost=4.65..118.62 rows=10 width=488) (actual time=0.128..0.377 rows=10 loops=1)
-> Bitmap Heap Scan on tenk1 t1 (cost=4.36..39.47 rows=10 width=244) (actual time=0.057..0.121 rows=10 loops=1)
Recheck Cond: (unique1 < 10)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..4.36 rows=10 width=0) (actual time=0.024..0.024 rows=10 loops=1)
Index Cond: (unique1 < 10)
-> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..7.91 rows=1 width=244) (actual time=0.021..0.022 rows=1 loops=10)
Index Cond: (unique2 = t1.unique2)
Total runtime: 0.501 ms
注意，实际时间(actual time)的值是已毫秒为单位的实际时间，cost是评估的消耗，是个虚拟单位时间，所以他们看起来不匹配。通常最重要的是看评估的记录数是否和实际得到的记录数接近。在这个例子里评估数完全和实际一样，但这种情况很少出现。
某些查询规划可能执行多次子规划。比如之前提过的内循环规划（nested-loop），内部索引扫描的次数是外部数据的数量。在这种情况下，报告显示循环执行的总次数、平均实际执行时间和数据条数。这样做是为了和评估值表示方式一至。由循环次数和平均值相乘得到总消耗时间。
某些情况EXPLAIN ANALYZE会显示额外的信息，比如sort和hash节点的时候：
EXPLAIN ANALYZE SELECT *
FROM tenk1 t1, tenk2 t2
WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2 ORDER BY t1.fivethous;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=717.34..717.59 rows=101 width=488) (actual time=7.761..7.774 rows=100 loops=1)
Sort Key: t1.fivethous
Sort Method: quicksort Memory: 77kB
-> Hash Join (cost=230.47..713.98 rows=101 width=488) (actual time=0.711..7.427 rows=100 loops=1)
Hash Cond: (t2.unique2 = t1.unique2)
-> Seq Scan on tenk2 t2 (cost=0.00..445.00 rows=10000 width=244) (actual time=0.007..2.583 rows=10000 loops=1)
-> Hash (cost=229.20..229.20 rows=101 width=244) (actual time=0.659..0.659 rows=100 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 28kB
-> Bitmap Heap Scan on tenk1 t1 (cost=5.07..229.20 rows=101 width=244) (actual time=0.080..0.526 rows=100 loops=1)
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.049..0.049 rows=100 loops=1)
Index Cond: (unique1 < 100)
Total runtime: 8.008 ms
排序节点（Sort）显示排序类型（一般是在内存还是在磁盘）和使用多少内存。哈希节点（Hash）显示哈希桶和批数以及使用内存的峰值。另一种额外信息是过滤条件过滤掉的记录数：
EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE ten < 7;
QUERY PLAN
---------------------------------------------------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..483.00 rows=7000 width=244) (actual time=0.016..5.107 rows=7000 loops=1)
Filter: (ten < 7)
Rows Removed by Filter: 3000
Total runtime: 5.905 ms
这个值在join节点上尤其有价值。"Rows Removed"只有在过滤条件过滤掉数据时才显示。类似条件过滤的情况也会在"lossy"索引扫描时发生，比如这样一个查询，一个多边形含有的特定的点：
EXPLAIN ANALYZE SELECT * FROM polygon_tbl WHERE f1 @> polygon '(0.5,2.0)';
QUERY PLAN
------------------------------------------------------------------------------------------------------
Seq Scan on polygon_tbl (cost=0.00..1.05 rows=1 width=32) (actual time=0.044..0.044 rows=0 loops=1)
Filter: (f1 @> '((0.5,2))'::polygon)
Rows Removed by Filter: 4
Total runtime: 0.083 ms
规划器认为（正确的）这样的表太小以至于不需要索引扫描，所以采用顺序扫描所有行经行条件检查。但是，如果我们强制使用索引扫描，将会看到：
SET enable_seqscan TO off;
EXPLAIN ANALYZE SELECT * FROM polygon_tbl WHERE f1 @> polygon '(0.5,2.0)';
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Index Scan using gpolygonind on polygon_tbl (cost=0.13..8.15 rows=1 width=32) (actual time=0.062..0.062 rows=0 loops=1)
Index Cond: (f1 @> '((0.5,2))'::polygon)
Rows Removed by Index Recheck: 1
Total runtime: 0.144 ms
这里我们可以看到索引返回一条候选数据，但被过滤条件拒绝。这是因为GiST索引在多边形包含检测上是松散的"lossy"：它实际返回哪些和多边形交叠的数据，然后我们还需要针对这些数据做包含检测。EXPLAIN还有BUFFERS选项可以和ANALYZE一起使用，来得到更多的运行时间分析：
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on tenk1 (cost=25.08..60.21 rows=10 width=244) (actual time=0.323..0.342 rows=10 loops=1)
Recheck Cond: ((unique1 < 100) AND (unique2 > 9000))
Buffers: shared hit=15
-> BitmapAnd (cost=25.08..25.08 rows=10 width=0) (actual time=0.309..0.309 rows=0 loops=1)
Buffers: shared hit=7
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.043..0.043 rows=100 loops=1)
Index Cond: (unique1 < 100)
Buffers: shared hit=2
-> Bitmap Index Scan on tenk1_unique2 (cost=0.00..19.78 rows=999 width=0) (actual time=0.227..0.227 rows=999 loops=1)
Index Cond: (unique2 > 9000)
Buffers: shared hit=5
Total runtime: 0.423 ms
Buffers提供的数据可以帮助确定哪些查询是I/O密集型的。
请注意EXPLAIN ANALYZE实际运行查询，任何实际影响都会发生。如果要分析一个修改数据的查询又不想改变你的表，你可以使用roll back命令进行回滚，比如：
BEGIN;
EXPLAIN ANALYZE UPDATE tenk1 SET hundred = hundred + 1 WHERE unique1 < 100;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------
Update on tenk1 (cost=5.07..229.46 rows=101 width=250) (actual time=14.628..14.628 rows=0 loops=1)
-> Bitmap Heap Scan on tenk1 (cost=5.07..229.46 rows=101 width=250) (actual time=0.101..0.439 rows=100 loops=1)
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.043..0.043 rows=100 loops=1)
Index Cond: (unique1 < 100)
Total runtime: 14.727 ms
ROLLBACK;
当查询是INSERT,UPDATE或DELETE命令时，在顶级节点是实施对表的变更。在这下面的节点实行定位旧数据计算新数据的工作。所以我们看到一样的bitmap索引扫描，并返回给Update节点。值得注意的是虽然修改数据的节点可能需要相当长的运行时间（在这里它消耗了大部分的时间），规划器却没有再评估时间中添加任何消耗，这是因为更新工作对于任何查询规划都是一样的，所以并不影响规划器的决策。EXPLAIN ANALYZE的"Total runtime"包括执行启动和关闭时间，以及运行被激发的任何处触发器的时间，但不包括分析、重写或规划时间。执行时间包括BEFORE触发器，但不包括AFTER触发器，因为AFTER是在查询运行结束之后才触发的。每个触发器（无论BEFORE还是AFTER）的时间也会单独显示出来。注意，延迟的触发器在事务结束前都不会被执行，所以EXPLAIN ANALYZE不会显示。
相关推荐
**PostgreSQL 12 手册详解** PostgreSQL 12是PostgreSQL数据库管理系统的一个重要版本，它提供了许多新特性和性能改进，旨在提升数据库管理的效率和灵活性。本手册全面覆盖了关于PostgreSQL 12的基础知识、高级概念...
- 使用`EXPLAIN ANALYZE`命令分析慢查询并优化索引结构。 - 调整`shared_buffers`、`work_mem`等配置参数以优化内存使用。 - 监控系统资源使用情况，并根据需要调整硬件配置。 ##### 2. **数据损坏** - **原因...
2. 性能分析：通过EXPLAIN和ANALYZE命令分析查询执行计划，找出性能瓶颈并进行优化。 本中文手册12.2版PostgreSQL.chm详细介绍了上述内容，适合初学者和有一定经验的开发者参考，以提升对PostgreSQL的理解和使用...
- 介绍PostgreSQL自带的性能分析工具，如`EXPLAIN ANALYZE`、`pg_stat_*`视图等。 - 了解第三方工具，如pgBadger、pgTAP等，用于更深层次的性能诊断。 - **性能指标监控**: - 学习如何监控CPU使用率、I/O等待时间...
**PostgreSQL安装配置详解** PostgreSQL是一款开源的关系型数据库管理系统（RDBMS），因其强大的功能和高度的稳定性而被广泛应用于各种规模的企业和项目中。本文档将详细讲解如何在不同的操作系统上安装和配置...
- 使用EXPLAIN命令进行性能瓶颈定位。 - 缓存机制优化策略。 - 数据库索引设计原则及最佳实践。 - 内存管理和参数设置技巧。 3. **备份与恢复** - 全量备份与增量备份的区别及其应用场景。 - 使用pg_dump工具...
可以通过`explain analyze`命令检查当前设置是否足够。 - **effective_cache_size**：表示计划查询时假设的操作系统磁盘缓存大小。设置较大的值有助于提高使用索引的效率。 - **maintenance_work_mem**：用于维护...
### PostgreSQL 表分区详解 #### 一、表分区概述 在数据库管理中，表分区是一种优化数据存储和查询性能的有效手段。特别是在处理大型数据集时，合理地利用表分区能够显著提升查询速度并减少资源消耗。PostgreSQL ...
**PostgreSQL数据库源码包详解** PostgreSQL是一种强大的开源关系型数据库管理系统（RDBMS），以其高度稳定性和丰富的功能著称。源码包提供了一种灵活性，允许用户根据特定需求自定义配置并编译安装，确保与操作...
**PostgreSQL数据库详解** PostgreSQL，通常简称为Postgres，是一种功能强大的开源关系型数据库管理系统（RDBMS），在全球范围内广泛应用于各种规模的企业和组织。它以其高度的稳定性、安全性以及对复杂SQL查询的...
- **EXPLAIN**：通过EXPLAIN命令分析查询计划，帮助优化查询性能。 5. **安全性与权限** - **角色与权限**：用户管理机制，包括创建、删除、修改用户角色，以及权限的分配和管理。 - **访问控制**：通过GRANT和...
- 使用 `EXPLAIN` 命令分析查询计划，帮助优化查询性能。 - 支持并行查询，提升大数据量处理速度。 4. **复制与高可用性** - PostgreSQL 提供流复制（Streaming Replication）功能，实现主备节点之间的实时数据...
**PostgreSQL 8 文件手册详解** PostgreSQL 8 是 PostgreSQL 数据库管理系统的一个早期版本，它提供了强大的关系数据库功能，支持多种编程语言，并以其开源、稳定和高性能而受到全球开发者的欢迎。本文将深入探讨 ...
同时，理解查询优化器的工作原理和EXPLAIN命令可以帮助我们编写更高效的SQL语句。 6. **安全性与权限管理**：PG提供用户角色、权限控制、SSL加密等功能，确保数据的安全性。理解如何设置和管理这些安全机制对于企业...
《PostgreSQL 9.6.0中文HTML手册详解》 PostgreSQL 9.6.0-CN-HTML-v1.0.tar.gz 是一个针对PostgreSQL数据库系统9.6.0版本的中文HTML手册，专为在Linux环境下使用设计，特别适合在内网机房中的运维人员参考。这个...
- **查询计划分析**：使用`EXPLAIN`命令来查看查询计划，并据此优化SQL语句。 - **并行查询**：PostgreSQL 9.6引入了并行查询功能，可以显著提高大型数据集处理的速度。 ##### 3. 高级优化技术 - **分区表**：通过...
3. 性能调优：理解查询计划，掌握EXPLAIN命令分析查询性能，以及VACUUM和REINDEX的使用。 六、高级特性 1. 触发器与存储过程：创建和管理触发器以实现特定业务逻辑，编写PL/pgSQL存储过程以封装复杂操作。 2. 事务...
### PGSQL常见的问题详解 #### 1. PostgreSQL是什么？该怎么发音？Postgres又是什么？ PostgreSQL，正确发音为“Post-Gres-Q-L”，是一个开源的关系型数据库管理系统(RDBMS)，它不仅提供了传统的商业数据库功能，...
### Oracle 常用命令详解 #### 一、概述 本文档主要介绍的是与PostgreSQL兼容的SQL命令，尽管标题提到的是“Oracle常用命令”，但实际内容覆盖的是PostgreSQL所支持的一系列SQL命令。这里提到的SQL即为结构化查询...
`pg_hint_plan` 提供了 `EXPLAIN ANALYZE HINTS` 命令，可以显示带有 hints 的执行计划，并收集实际执行时间，这对于性能调优非常有帮助。同时，结合 PostgreSQL 的其他监控工具，如 `pg_stat_statements`，可以...