postgres 执行计划 execution planing

最新推荐文章于 2023-09-17 16:51:35 发布
最新推荐文章于 2023-09-17 16:51:35 发布
阅读量446 收藏
点赞数
分类专栏： Database
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/tina_tian1/article/details/83277367
版权

1. 查询

 通过索引查询

idm_prod_20180405=# \d token_store;
                   Table "public.token_store"
        Column        |            Type             | Modifiers 
----------------------+-----------------------------+-----------
 uuid                 | character varying(50)       | not null
 request_token        | character varying(50)       | 
 authentication_token | text                        | 
 subject              | character varying(50)       | 
 expiration           | timestamp without time zone | 
 token_id             | character varying(50)       | 
 refresh_before       | timestamp without time zone | 
 refresh_id           | character varying(50)       | 
Indexes:
    "token_store_new_pkey" PRIMARY KEY, btree (uuid)
    "token_store_new_request_token_idx" btree (request_token)
idm_prod_20180405=# explain analyze select * from token_store where request_token = '77c7811d-637a-4247-8635-59ed75bdc526';
                                                                    QUERY PLAN                                        
                            
----------------------------------------------------------------------------------------------------------------------
----------------------------
 Index Scan using token_store_new_request_token_idx on token_store  (cost=0.28..8.30 rows=1 width=1358) (actual time=0
.061..0.064 rows=1 loops=1)
   Index Cond: ((request_token)::text = '77c7811d-637a-4247-8635-59ed75bdc526'::text)
 Planning time: 0.167 ms
 Execution time: 0.182 ms
(4 rows)

 

 无索引查询
idm_prod_20180405=#  drop index token_store_new_request_token_idx;
DROP INDEX
idm_prod_20180405=# \d token_store;
                   Table "public.token_store"
        Column        |            Type             | Modifiers 
----------------------+-----------------------------+-----------
 uuid                 | character varying(50)       | not null
 request_token        | character varying(50)       | 
 authentication_token | text                        | 
 subject              | character varying(50)       | 
 expiration           | timestamp without time zone | 
 token_id             | character varying(50)       | 
 refresh_before       | timestamp without time zone | 
 refresh_id           | character varying(50)       | 
Indexes:
    "token_store_new_pkey" PRIMARY KEY, btree (uuid)
idm_prod_20180405=# explain analyze select * from token_store where request_token = '77c7811d-637a-4247-8635-59ed75bdc526';
                                                QUERY PLAN                                                 
-----------------------------------------------------------------------------------------------------------
 Seq Scan on token_store  (cost=0.00..942.64 rows=1 width=1358) (actual time=0.031..10.595 rows=1 loops=1)
   Filter: ((request_token)::text = '77c7811d-637a-4247-8635-59ed75bdc526'::text)
   Rows Removed by Filter: 6200
 Planning time: 0.236 ms
 Execution time: 10.641 ms
(5 rows)

PS：

idm_prod_20180405=# select count(*) from token_store ;
 count 
-------
  6201
(1 row)
 

2. Join

idm_prod_20180405=# explain analyze   SELECT o.* FROM abstract_user u

idm_prod_20180405-# INNER JOIN organizations o on (u.display_name = 'tx' and u.organization = o.uuid )

idm_prod_20180405-# INNER JOIN roles_users ru on ru.user_id = u.uuid

idm_prod_20180405-# INNER JOIN roles r on (ru.role_id = r.uuid )

idm_prod_20180405-# INNER JOIN permission_role rp on rp.role_id = r.uuid

idm_prod_20180405-# INNER JOIN permission p on (p.uuid = rp.permission_id )

idm_prod_20180405-# WHERE upper(p.name) in ('BYOIP') and o.deleted is null and r.deleted is null and p.deleted is null and u.deleted is null ;

                                                                             QUERY PLAN                                                                            

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Nested Loop  (cost=1.39..212.33 rows=1 width=192) (actual time=2.371..4.317 rows=3 loops=1)

   Join Filter: ((ru.role_id)::text = (r.uuid)::text)

   ->  Nested Loop  (cost=1.11..212.00 rows=1 width=258) (actual time=2.330..4.207 rows=3 loops=1)

         ->  Nested Loop  (cost=0.97..209.31 rows=15 width=289) (actual time=2.267..3.289 rows=26 loops=1)

               ->  Nested Loop  (cost=0.56..208.23 rows=1 width=225) (actual time=2.183..3.021 rows=3 loops=1)

                     ->  Nested Loop  (cost=0.28..199.92 rows=1 width=225) (actual time=0.216..2.851 rows=5 loops=1)

                           ->  Seq Scan on abstract_user u  (cost=0.00..191.61 rows=1 width=66) (actual time=0.145..2.640 rows=5 loops=1)

                                 Filter: ((deleted IS NULL) AND ((display_name)::text = 'tx'::text))

                                 Rows Removed by Filter: 4572

                           ->  Index Scan using organizations_pkey on organizations o  (cost=0.28..8.29 rows=1 width=192) (actual time=0.035..0.037 rows=1 loops=5)

                                 Index Cond: ((uuid)::text = (u.organization)::text)

                                 Filter: (deleted IS NULL)

                     ->  Index Scan using ru_u_index on roles_users ru  (cost=0.28..8.30 rows=1 width=66) (actual time=0.030..0.031 rows=1 loops=5)

                           Index Cond: ((user_id)::text = (u.uuid)::text)

               ->  Index Only Scan using permission_role_pk on permission_role rp  (cost=0.41..0.97 rows=11 width=64) (actual time=0.065..0.077 rows=9 loops=3)

                     Index Cond: (role_id = (ru.role_id)::text)

                     Heap Fetches: 26

         ->  Index Scan using roles_pkey on permission p  (cost=0.14..0.17 rows=1 width=32) (actual time=0.033..0.033 rows=0 loops=26)

               Index Cond: ((uuid)::text = (rp.permission_id)::text)

               Filter: ((deleted IS NULL) AND (upper((name)::text) = 'BYOIP'::text))

               Rows Removed by Filter: 1

   ->  Index Scan using roles_pkey1 on roles r  (cost=0.28..0.32 rows=1 width=33) (actual time=0.030..0.031 rows=1 loops=3)

         Index Cond: ((uuid)::text = (rp.role_id)::text)

         Filter: (deleted IS NULL)

Planning time: 13.906 ms

Execution time: 4.543 ms

(26 rows)

 

idm_prod_20180405=# explain analyze  SELECT o.* FROM abstract_user u

idm_prod_20180405-# INNER JOIN organizations o on (u.display_name = 'tx' and u.organization = o.uuid and u.deleted is null and o.deleted is null)

idm_prod_20180405-# INNER JOIN roles_users ru on ru.user_id = u.uuid

idm_prod_20180405-# INNER JOIN roles r on (ru.role_id = r.uuid and r.deleted is null)

idm_prod_20180405-# INNER JOIN permission_role rp on rp.role_id = r.uuid

idm_prod_20180405-# INNER JOIN permission p on (p.uuid = rp.permission_id and p.deleted is null)

idm_prod_20180405-# WHERE upper(p.name) in ('BYOIP')

idm_prod_20180405-# ;

                                                                             QUERY PLAN                                                                             

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Nested Loop  (cost=1.39..212.33 rows=1 width=192) (actual time=2.381..4.418 rows=3 loops=1)

   Join Filter: ((ru.role_id)::text = (r.uuid)::text)

   ->  Nested Loop  (cost=1.11..212.00 rows=1 width=258) (actual time=2.340..4.307 rows=3 loops=1)

         ->  Nested Loop  (cost=0.97..209.31 rows=15 width=289) (actual time=2.277..3.351 rows=26 loops=1)

               ->  Nested Loop  (cost=0.56..208.23 rows=1 width=225) (actual time=2.189..3.091 rows=3 loops=1)

                     ->  Nested Loop  (cost=0.28..199.92 rows=1 width=225) (actual time=0.245..2.916 rows=5 loops=1)

                           ->  Seq Scan on abstract_user u  (cost=0.00..191.61 rows=1 width=66) (actual time=0.170..2.688 rows=5 loops=1)

                                 Filter: ((deleted IS NULL) AND ((display_name)::text = 'tx'::text))

                                 Rows Removed by Filter: 4572

                           ->  Index Scan using organizations_pkey on organizations o  (cost=0.28..8.29 rows=1 width=192) (actual time=0.037..0.039 rows=1 loops=5)

                                 Index Cond: ((uuid)::text = (u.organization)::text)

                                 Filter: (deleted IS NULL)

                     ->  Index Scan using ru_u_index on roles_users ru  (cost=0.28..8.30 rows=1 width=66) (actual time=0.031..0.032 rows=1 loops=5)

                           Index Cond: ((user_id)::text = (u.uuid)::text)

               ->  Index Only Scan using permission_role_pk on permission_role rp  (cost=0.41..0.97 rows=11 width=64) (actual time=0.061..0.075 rows=9 loops=3)

                     Index Cond: (role_id = (ru.role_id)::text)

                     Heap Fetches: 26

         ->  Index Scan using roles_pkey on permission p  (cost=0.14..0.17 rows=1 width=32) (actual time=0.035..0.035 rows=0 loops=26)

               Index Cond: ((uuid)::text = (rp.permission_id)::text)

               Filter: ((deleted IS NULL) AND (upper((name)::text) = 'BYOIP'::text))

               Rows Removed by Filter: 1

   ->  Index Scan using roles_pkey1 on roles r  (cost=0.28..0.32 rows=1 width=33) (actual time=0.030..0.032 rows=1 loops=3)

         Index Cond: ((uuid)::text = (rp.role_id)::text)

         Filter: (deleted IS NULL)

Planning time: 13.250 ms

Execution time: 4.638 ms

(26 rows)

 

idm_prod_20180405=#

以上红色部分可以看出数据库对sql做过优化处理，
 

tina_tian1
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
nacos支持postgres
11-06
3. **表结构创建**：Nacos在启动时会自动创建所需的表结构，如果PostgreSQL中没有预先创建，需要确保Nacos有足够的权限来执行这些SQL脚本。 4. **启动Nacos**：配置完成后，重新启动Nacos服务，它将尝试连接到配置...
postgres安装包
11-23
postgres
【GP】执行计划
cml2016的博客
05-22 1404
执行计划 (Execution Plan) 什么执行计划? Postgres 有一个强大的功能可以想你展示数据库内容怎样执行一个查询. 这里所谓的执行计划是 通过explain展...
查看postgres的执行计划
文档搬运工
06-21 1118
查看postgres版本 -bash-4.2$ pg_config --version PostgreSQL 10.15 -bash-4.2$
PostgreSQL执行计划
weixin_39735909的博客
09-17 395
这种方式适用于较小的表可以完全放于内存中的情况，这样总成本就是访问两个表的成本之和。但是如果表很大，不能完全放入内存，优化器会将它分割成若干不同的分区，把不能放入内存的部分写入磁盘的临时段，此时要有较大的临时段从而尽量提高I/O的性能。在嵌套循环中，内表被外表驱动，外表返回的每一行都要在内表中检索找到与它匹配的行，因此整个查询返回的结果集不能太大（大于1万不适合），要把返回子集较小的表作为外表，而且在内表的。索引扫描，就是在索引中找出需要的数据行的物理位置，然后再到表的数据块中把相应的数据读出来的过程。
跟我一起读postgresql源码(九)——Executor(查询执行模块之——Scan节点(上))
weixin_30352645的博客
01-13 386
从前面介绍的可优化语句处理相关的背景知识、实现思想和执行流程，不难发现可优化语句执行的核心内容是对于各种计划节点的处理，由于使用了节点表示、递归调用、统一接口等设计，计划节点的功能相对独立、代码总体流程相似，下面介绍执行器中各种计划节点的相关执行过程。 在PostgreSQL中，计划节点分为四类，分别是控制节点（Control Node)、扫描节点（ScanNode),物化节点（Materiali...
postgres的 Planning Time和Execution Time区别
danns888的专栏
09-09 1728
Planning Time和Execution Time相差很大，其实互相比较没什么意思 因为Planning Time是指定一个执行查询的最快方式（计划）所需的时间，postgres有一个"query planner" 来实现的 而Execution Time是运行这个最快的查询计划，并且将结果输出的时间 下面国外的文章很好的解释了两者的区别： You write a query in SQL which is some kind of "script" that you try to te...
Docker postgres:16-alpine镜像
最新发布
06-07
非常好用的docker postgres:16-alpine镜像 sha256: f1bf85e5d935e617586b71c507094685f6b7c66de4fed41554c496718ebc9c59 导入docker直接使用
postgres数据库数据探查
07-20
本资源使用python进行编写，解压后在pycharm中进行使用，该探查数据库适用于postgres数据库，运行结束后以.xlsx格式进行保存，探查的内容有：数据库名称、数据表名称、数据表注释、排序、字段名称、字段注释、字段...
postgressql-16.0.1 windows x64
10-08
16新特性： 1.权限管理 2.逻辑复制增强功能 3.性能提升：并行查询方面的性能提升，比如允许FULL和RIGHT JION在并行模式下执行，支持SIMD 4.全面的监控功能
事务基础知识与执行计划
码云仓库地址：https://gitee.com/lance-gyq
02-11 774
(4）KES使用的是基于代价（COST）的执行计划，它是优化器对于该语句要运行多久的预估。(5）执行计划会显示启动代价和总代价，对于大部分查询来讲总代价是最需要被关注的。(1)执行计划（Execution Plan)描述SQL语句在数据库中的执行过程，常用于SQL 性能分析。注意：输出XML、JSON、YAML格式，一般是为了方便某些背程序或脚本抓取处理。注意：不能在一个被设置为只读模式的事物中执行DML、DDL、DCL操作。(2）它是数据库查询优化器选择出来的执行语句的方案。
postgresql分区表探索(pg_pathman)
weixin_30648963的博客
08-20 497
使用场景 许多系统在在使用几年之后数据量不断膨胀，这个时候单表数据量超过2000w+，数据库的查询也越来越慢，而随着时间的推移许多历史数据的重要性可能逐渐下降。这时候就可以考虑使用分区表来将冷热数据分区存储。 常用的使用场景比如sql分析的日志记录，常用的分区字段有按照创建时间、省份、以及业务类型，具体使用需要结合需求 Postgresql官方的建议是单表大小超过了服务器内存大小可以考虑分区...
因接触partition by而对PostgreSQL explain有了一个小小的认识
Herishwater的博客
12-04 1931
偶然情况下看到了别人写的关于 partition by 使用的 SQL，以及提到的索引使用，因为对这方面的知识有所欠缺，所以决定花点时间学习一下，于是就有了下文。 环境搭建及筹备样本数据 本文使用 Postgre SQL 数据库，版本号为 12.8。 创建数据表 关于数据库连接有如下三种方式： 1、使用 psql 连接到 PostgreSQL 数据库。psql 是 PostgreSQL 提供的交互式终端程序。通过 psql 工具，可以执行大量操作，比如：执行 SQL 语句、管理数据库对象等等。查看版本号（s
postgresql——执行计划查看方式与计划分析【转】
热门推荐
徐本锡的专栏
06-14 120万+
执行计划查看命令 explain[(option[,…])] explain [analyze][verbose]statement 可选的option选项有： analyze[boolean]：得到statement的真实运行时间。默认是false verbose[boolean]：得到statement语句的执行计划和执行计划中的每个节点的详细信息。默认为false costs[boolean]：得到计划中每个接地哪的cost，rows，width的估算值，默认为true buffers[bo
Postgresql：查看执行一条SQL语句所用的时间及过程摘要
你好，PurePeace！
12-01 7160
有时候需要进行SQL语句的优化，这时就需要先分析一下语句的执行情况： 我们得知道语句执行花了多少时间，以及语句执行的过程。 现在我有一个存放用户登录记录的表login_records，其中有100万条数据： SELECT COUNT(1) FROM "user"."login_records" WHERE "user_id" = 1000; 查询一下表的行数，结果： count --------- 1000000 (1 row) 那么，我执行上面这条SQL语句花费了多长时间呢？ 在Postgre
如何看懂Postgres的执行计划
kiwi的专栏
03-14 1万+
如何看懂Postgres的执行计划 test=# insert into test select id from (select generate_series(1,10000000))ids(id); INSERT 0 10000000 Time: 39656.016 ms test=# select * from test where id=1; id ---- 1 (1 row)
postgresql查看sql执行所用时间以及过程摘要
gggg989898的博客
02-20 5939
文章目录使用场景一、使用 EXPLAIN ANALYZE 命令二、使用步骤1.一般查询2.使用命令总结 使用场景 有时候需要进行SQL语句的优化，这时就需要先分析一下语句的执行情况，我们要知道sql执行的时间，以及执行的过程 提示：以下是本篇文章正文内容，下面案例可供参考 一、使用 EXPLAIN ANALYZE 命令 示例：pandas 是基于NumPy 的一种工具，该工具是为了解决数据分析任务而创建的。 二、使用步骤 1.一般查询 SELECT count(id) from t_user; 2..
postgres执行计划和索引
u012736152的专栏
11-13 1244
postgresql执行计划和索引 文章目录postgresql执行计划和索引执行计划命令关键字节点解释节点解释节点解释节点解释如何阅读查看pg执行计划 执行计划 命令 explain[(option[,...])] explain analyzestatement 可选的option选项有： Analyze[boolean]：得到statement的真实运行时间。默认是false verbose[boolean]：得到statement语句的执行计划和执行计划中的每个节点的详细信息。默认为false co
PostgreSQL中EXPLAIN的使用
HighGO
09-06 7375
查询计划的结构是一个计划结点的树。最底层的结点是扫描结点：它们从表中返回未经处理的行。 1.EXPLAIN简介 EXPLAIN给计划树中每个结点都输出一行，显示基本的结点类型和计划器为该计划结点的执行所做的开销估计。 第一行（最上层的结点）是对该计划的总执行开销的估计。 举一个简单的例子来展示EXPLAIN的输出结果： postgres=# explain select * from t...
postgres 查询计划
10-12
优化器会分析查询语句并生成多个可能的执行计划，然后评估每个计划的成本，并选择成本最低的计划作为最终的查询计划。 查询计划的生成过程包括选择合适的连接顺序，选择合适的操作顺序，以及对各种操作的使用技巧。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值