云数据库 RDS PostgreSQL 版优化器的相关内容

问答 2023-07-12 来自：开发者社区

云原生数据仓库AnalyticDB PostgreSQL 有没有被优化器指定为串行计算了呢？

问题1：云原生数据仓库AnalyticDB PostgreSQL看曲线像是是没有使用到其他节点，有没有被优化器指定为串行计算了呢？我能不能指定并行计算测试下效率。问题2：如果是这个情况,那我单独跑23266062这个节点的计算可以复现。但是我现在创建8个物化视图,添加条件 where gp_segment_id = 0～7 ，并没有出现这个情况，这是为什么？

文章 2021-10-10 来自：开发者社区

【重新发现PostgreSQL之美】- 38 肝者,将军之官,谋虑出焉. 优化器

背景场景:HTAP业务, 企业级OLTP业务.ORM(自动生成SQL, 无法优化, 数十表的SQL JOIN)挑战:优化器弱无法选择最佳执行路径,统计信息不及时, 无法得出最佳执行计划,环境: ssd, disk 多种不同硬件组成的表空间, 怎么才能算出最佳代价执行器弱支持的数据扫描、计算方法少的可怜.PG 解决方案:优化器强大执行器强大支持扩展执行器支持并行计算、JITPG的将军之官 - 优化....

文章 2019-04-27 来自：开发者社区

PostgreSQL JOIN limit 优化器成本计算改进 - mergejoin startup cost 优化

标签 PostgreSQL , join , limit , startup cost , cbo , 优化器改进背景 PostgreSQL limit N的成本估算，是通过计算总成本A，以及估算得到的总记录数B得到： (N/B)*A 大概意思就是占比的方法计算对于单表查询，这种方法通常来说比较适用，但是如果数据分布有倾斜，实际上也并不一定适用，例如以下两种情况： 1、符...

文章 2019-04-14 来自：开发者社区

PostgreSQL 当有多个索引可选时，优化器如何选择

标签 PostgreSQL , 索引 , 复合索引 , 选择 , 成本 , 优化器背景当一个表有很多索引时，并且一个QUERY可以使用到其中的多个索引时，数据库会如何做出选择？最终选择哪个，或者哪几个索引呢？《PostgreSQL 多查询条件，多个索引的选择算法与问题诊断方法》选择单个索引时，PATH可以选择index scan , index only scan, bitmap s...

文章 2019-03-05 来自：开发者社区

PostgreSQL优化器之从一个关于扫描方式选择引发的思考

一个关于PostgreSQL使用组合索引的问题近期阅读了《数据库查询优化器的艺术》这本书，对PG和Mysql优化器技术的轮廓有了一定了解。在阅读的过程中，因为知识背景和书本身的表述问题产生了许多困惑，这里就分享对其中一个困惑的探索过程作为看完书的总结。在这本书的第十八章，关于PG和Mysql的优化器对于索引的优化能力对比中的一段让我困惑不已。如图一所示，单独使用组合索引的后半部分作为查询条件使....

文章 2019-02-25 来自：开发者社区

PostgreSQL技术周刊第16期：PostgreSQL 优化器代码概览

PostgreSQL（简称PG）的开发者们：云栖社区已有5000位PG开发者，发布了3000+PG文章（文章列表），沉淀了700+的PG精品问答（问答列表）。 PostgreSQL技术周刊将会为大家介绍最新的PG技术与动态、预告活动、最热问答、直播教程等，欢迎大家订阅PostgreSQL技术周刊和关注PostgreSQL社区公众号。直播预告德哥PG系列课程直播（第14讲）：Postgr...

文章 2019-02-18 来自：开发者社区

PostgreSQL 优化器代码概览

简介 PostgreSQL 的开发源自上世纪80年代，它最初是 Michael Stonebraker 等人在美国国防部支持下创建的POSTGRE项目。上世纪末，Andrew Yu 等人在它上面搭建了第一个SQL Parser，这个版本称为Postgre95，也是加州大学伯克利分校版本的PostgreSQL的基石[1]。我们今天看到的 PostgreSQL 的优化器代码主要是 Tom Lane....

文章 2018-10-23 来自：开发者社区

PostgreSQL JOIN limit 优化器成本计算改进 - mergejoin startup cost 优化

背景PostgreSQL limit N的成本估算，是通过计算总成本A，以及估算得到的总记录数B得到： (N/B)*A 大概意思就是占比的方法计算对于单表查询，这种方法通常来说比较适用，但是如果数据分布有倾斜，实际上也并不一定适用，例如以下两种情况： 1、符合条件的数据占总记录数的50%，但是全部分布在表的末尾，那么limit 10000 条到底是走索引快还是走全表扫描快呢？ 2、符合条...

文章 2018-10-05 来自：开发者社区

PostgreSQL 优化器案例之 - order by limit 索引选择问题

标签 PostgreSQL , limit , order by , 优化器 , 选择性 , 相关性 , 数据存储顺序 , 目标数据存储顺序背景当我们在执行一个这样的SQL时，假如有这样几个索引(c1,c2) (id)，数据库到底该用哪个索引呢？ explain select * from tbl where c1=200 and c2=200 order by id limit 10;...

文章 2018-10-05 来自：开发者社区

PostgreSQL 优化器知识之 - stable 函数调用次数

标签 PostgreSQL , 三态 , stable , 调用次数背景 immutable 函数，输入参数静态时，返回结果不变，所以它在plan前先计算，得到一个常量后，放到QUERY里面再生成执行计划。 stable 函数，输入参数静态时，如果在一个事务中多次调用它，返回结果不变。显然一个immutable 函数在同一个SQL中，永远只调用一次，（在bind , execute的模式...