greenplum 生成执行计划慢的一种情况

最新推荐文章于 2022-09-09 15:55:04 发布
原创 最新推荐文章于 2022-09-09 15:55:04 发布 · 354 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#数据库

在Greenplum 4.3.33版本中，遇到生成执行计划耗时7秒的问题，主要原因是当表缺乏统计信息时，系统会尝试获取表的实际大小，包括页数和行数，这一过程在多分区表和列较多的情况下尤其耗时。解决方案是利用gp_enable_relsize_collection参数来控制优化器是否查询表的实际大小。

greenplum 4.3.33 版本遇到生成执行计划需要7秒左右的时间，相关信息如下：

Thread 2 (Thread 0x7f64eac77700 (LWP 31116)):
#0 0x00007f64e65acdfd in poll () from /lib64/libc.so.6
#1 0x0000000000bbb034 in rxThreadFunc (arg=) at ic_udpifc.c:6313
#2 0x00007f64e70acdc5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f64e65b773d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f64ead19740 (LWP 31115)):
#0 0x00000000004ffecf in hashlittle (length=26, key=, initval=) at hashfunc.c:444
#1 hash_any (k=, keylen=) at hashfunc.c:1083
#2 0x00000000005f689a in caql_get_parser_cache (len=, str=) at caqlanalyze.c:602
#3 cq_lookup (str=0xdbb0bc "M pg_type WHERE oid = :1 ", len=26, pcql=0xa83f019a) at caqlanalyze.c:78
#4 0x00000000005f7937 in caql_beginscan (pCtx0=0x0, pcql=0x8bddd68) at catquery.c:714
#5 0x0000000000aefd2f in get_typlen (typid=) at lsyscache.c:2024
#6 get_typavgwidth (typid=20, typmod=-1) at lsyscache.c:2469
#7 0x00000000008d39f3 in estimate_tuple_width (rel=0x28434c8, attr_widths=0xd9d1cb8, bytes_per_tuple=0x7ffe7bb3ee1c, tuples_per_page=0x7ffe7bb3ee08) at plancat.c:629
#8 0x00000000008d4c90 in cdb_estimate_rel_size (default_stats_used=, tuples=, pages=, attr_widths=, rel=, baserel=, relOptInfo=) at plancat.c:434
#9 get_relation_info (root=0x2463830, relationObjectId=313961, inhparent=, rel=) at plancat.c:136

最低0.47元/天 解锁文章
第22课：Greenplum 的执行计划
张树杰的博客
09-22 1011
Greenplum 是脱胎于 PostgreSQL 的分布式数据库。既然是分布式数据库，原来 PostgreSQL 生成的基于单机数据库的执行计划显然就无法使用了。因此，本章要分析的是 Greenplum 如何改进 PostgreSQL 的执行计划，使其能够在分布式数据库中执行。 数据分布不同了 Greenplum 中有多个结点，最主要的是划分成了 Master 结点和 Segment 结点。每个...
greenplum 执行计划
weixin_33881041的博客
12-21 723
1、GreenPlum这种share nothing的架构： 良好的发挥了廉价PC的作用。自此I/O不在是DW的瓶颈，相反网络的压力会大很多。但是greenplum的查询优化策略能够避免尽量少的网络交换。对于初次接触greenplum的人来说，肯定耳目一新。2、greenplum的查询优化器greenplum的查询优化器负责将SQL解析成每个节点(segme...
记一次greenplum集群数据库连接慢的问题定位
mirai_D_zoro的博客
07-05 1122
集群状态 gpstate -c 查看当前并发进程数量 select count(1) from pg_stat_activity; 查看死锁 SELECT distinct w.current_query as waiting_query, w.procpid as w_pid, w.usename as w_user, l.current_query as locking_query, l.procpid as l_pid, l.usename as l_user, t.s
Greenplum闰秒故障的分析解决
泰克轱辘儿
07-17 1982
2015年7月1日上午，国家授时中心增加了7:59:60这个时间来处理闰秒问题。对于使用网络时间协议进行时钟同步的操作系统而言，实在是不应该有什么问题才对，因为即使没有这多出的一秒，系统时钟不准个几秒也是常有的事儿啊。但是部分Linux（比如RHEL 6.2 64bit）上的部分应用（比如Greenplum数据库，也包括java和mysql这些）需要读取硬件时钟和系统时钟，这二者不一致时，就跑不动
Greenplum问题定位及性能调优
Greenplum中文社区
07-16 1265
...
MySQL增加普通索引
weixin_45739720的博客
12-09 694
1、查看索引 show index from student 2、增加主键索引 #增加主键索引 alter table student add primary key (sno); 3、增加普通索引 #增加普通索引 create index name_index on student(sname); 4、添加全文索引 5、查看执行计划 #查看执行计划 explain select * f...
Greenplum内核揭秘之执行引擎
知识的力量
06-09 632
Greenplum内核揭秘之执行引擎 目录 Greenplum内核揭秘之执行引擎 1 目录 1 1 执行器介绍 2 1.1 什么是执行器 2 1.2 PlanNode(执行计划节点) 2 1.3 PlanTree(执行计划树) 2 1.3 执行模型 3 1.3.1 迭代模型(Pipeline模型，Pull方式) 3 1.3.2 向量化模型(VECTORIZATION Model) 3 1.3.3 PUSH执行模型 4 1.3.4 PUSH模型的优势 4 1.3.5 GPDB使用的模
基于Greenplum数据库的查询优化
03-30
本文以Greenplum分布式数据库为研究对象，提出了一种基于代价的最优查询计划生成方法，旨在解决这一挑战。 ### Greenplum数据库简介 Greenplum是基于PostgreSQL的开源分布式数据库，专为数据仓库应用而设计。它...
gethostbyname超时，与遇到的一些坑
weixin_34120274的博客
09-04 3321
现网有些DNS服务器质量不好，经常不返回，导致服务器在做DNS请求时经常被卡住，简单测试后发现如果服务器不返回结果，一般20+秒超时。但是如果使用alarm和signal，是不能中断系统函数的，参考了一些网络上的资料，可以设置sigsetjmp和siglongjmp来打断系统函数，并可以恢复之前的堆栈，避免发生问题。 static sigjmp_buf jmpbuf; static void al...
Greenplum 执行计划中的术语 摘自书籍
是个好男人的博客
07-09 817
摘自书籍：Greenplum企业应用实战 完整版[何勇，陈晓峰著] 1.数据扫描方式 Seq Scan：顺序扫描 顺序扫描将一个数据文件从头到尾读取一次，这种方式非常符合磁盘的读写特性，顺序读写，吞吐很高。对于分析性的语言，顺序扫描基本上是对全表的所有数据进行分析计算，在是数据仓库中，大都为这种扫描，结合压缩表使用，可以减少磁盘IO的损耗。 Index Scan：索引扫描 索引扫描是通过索引来定位数据的，一般对数据进行特定的筛选，筛选后的数据量比较小（对于整个表而言）。...
mysql-MVCC机制
小小少年的博客
11-10 484
结论 在对版本链中的事务ID进行比较时，有以下规则： 如果版本链中的事务ID，落在最左边区域(tx_id < min_id)，那表示当前版本是已经提交的事务，是可见的 如果版本链中的事务ID，是落在右边部分(tx_id > max_id)，表示这个版本是由将来启动的事务生成的(将来的事务，也就是当前session生成事务ID之后，有其他session生成的新的事务ID)，是不可见的 如果版本链中的事务ID，是落在中间区域(min_id <= tx_id <= max_id
【Greenplum】insert数据入库速度优化
BIG BOSS的博客
07-29 5616
使用geotools入库很慢，1万条数据147秒。 换成Jdbc直接运行insert语句，1万条118秒。 速度非常慢，而且更换Driver速度差不多一模一样。 private String diverClassName="org.postgresql.Driver";//推荐使用 private String diverClassName="com.pivotal.jdbc.GreenplumDriver"; 优化 greenplum的master端口需要改成5432，不然gpconfig用不
Greenplum执行计划
Focus on PostgreSQL
01-20 3675
Greenplum执行计划和pg中的类似，但是由于gp是分布式的shared nothing架构，所以执行计划必然和pg还是有些区别。 gp中查看SQL的执行计划也是通过explain语句，语法如下： Command: EXPLAIN Description: show the execution plan of a statement Syntax: EXPLAIN [ ANALYZE ...
Greenplum广播与重分布原理
代元培
09-09 1271
Greenplum 的执行计划和 PostgreSQL 基本一致，但是在表关联的时候还是会有区别，因为 greenplum 中数据不同于 pg，greenplum 是将数据分布在多个节点上。所以当两表关联时关联列又不是表的分布键时就会出现表的广播和重分布。本文将详细介绍广播和重分布的区别及场景。
greenplum常见问题及解决方法
热门推荐
q936889811的博客
01-02 4万+
文章目录1、错误：数据库初始化：gpinitsystem -c gpconfigs/gpinitsystem_config -h list2、错误 ：执行检查：gpcheck -f list3、错误：gpadmin-[CRITICAL]:-gpstate failed. (Reason='Environment Variable MASTER_DATA_DIRECTORY not set!') e...
Greenplum在企业生产中的最佳实践（上）
weixin_33860553的博客
07-29 405
本文章转自Pivotal公众号，在此感谢任振中和Pivotal公司的分享，希望对更多的朋友有帮助～ 一、GP搭建过程当中硬件的选择和部署建议 GP是一个分布式X86架构，是把多台X86服务器组合成一起做一个大的集群。相比传统单机版的Oracle和MySQL，它的特点是使用比较多的服务器做海量数据处理。 一般在企业客户中，把X86服务器采集过来后会做上...
多年DBA实战经验：Greenplum数据库优化技巧与实践
ludongguoa的博客
11-05 1131
熟悉Greenplum的小伙伴都知道，Greenplum是一款分布式数据库。MPP架构相较于传统的SMP架构更能快速响应分析型应用的需求。利用MPP架构的优势，Greenplum可以处理海量数据。2021数据库大咖讲坛第6期《数据库性能优化技巧与最佳实践》活动中，来自Greenplum中文社区的阿福（苑泽福）发表演讲《Greenplum数据库优化技巧与实践》。下面让我们通过本篇文章回顾一下精华内容。 本篇内容主要包括三个部分，从架构入手，延伸到Greenplum的功能特点，针对不同的功能特点提出针对性优化
greenplum执行max()
最新发布
04-01
<think>嗯，用户问的是在Greenplum中正确执行MAX()函数或解决相关问题。首先，我需要回想一下Greenplum的基本架构，它是一个基于PostgreSQL的MPP数据库，适用于大数据分析。MAX()函数作为聚合函数，在Greenplum中的使用应该和PostgreSQL类似，但需要注意分布式环境下的性能问题。 首先，用户可能遇到的问题可能有几种情况。比如，MAX()函数返回的结果不符合预期，或者在执行时出现性能问题。需要分步骤来分析。例如，检查数据类型是否支持比较，如果字段是字符串类型，可能排序规则影响结果。或者，在分布式表中，数据分布键的选择可能影响聚合的效率。 接下来，正确的使用方法是关键。要确保用户知道MAX()可以用于数值、日期或字符串类型，并且可以在查询中单独使用或结合GROUP BY。比如，用户可能需要按某个字段分组后取最大值，这时候需要正确编写SQL语句。 然后，性能优化方面，Greenplum的分布式特性可能导致全表扫描，如果表很大，执行MAX()会慢。这时候可以考虑在相关字段上创建索引，或者调整分布策略，比如使用哈希分布在某个列上，或者将表改为随机分布，避免数据倾斜导致某些节点负载过高。 另外，常见错误处理也是用户需要的。例如，如果字段包含NULL值，MAX()会忽略它们，但用户可能需要处理NULL的情况。或者，如果字段类型不支持比较，比如JSON类型，这时候需要转换类型或者使用其他函数。 还有，用户可能需要结合其他函数，比如窗口函数，来实现更复杂的需求。比如，获取每个分组的最大值同时显示其他列的值，这时候ROW_NUMBER()或者DISTINCT ON可能更合适。 最后，生成相关问题需要考虑用户可能的后续疑问，比如性能调优、特定场景下的应用、错误处理等。确保问题覆盖用户可能遇到的深层次问题，帮助他们进一步学习。</think>### Greenplum中MAX()函数使用与问题排查指南 #### 一、MAX()函数基本用法 1. **数值型数据**： ```sql SELECT MAX(salary) FROM employees; -- 获取工资字段最大值 ``` 注意：Greenplum会自动跳过NULL值，保留精度最高的数值类型结果[^1] 2. **日期类型**： ```sql SELECT MAX(order_date) FROM sales WHERE region = 'Asia'; -- 获取亚洲地区最新订单日期 ``` 3. **字符类型**： ```sql SELECT MAX(product_name) FROM products; -- 按字母顺序返回最大字符串值 ``` #### 二、性能优化技巧 1. **索引优化**： ```sql CREATE INDEX idx_sales_date ON sales(order_date); -- 为日期字段创建B-tree索引 ``` 当执行`SELECT MAX(order_date)`时，索引可提升100倍查询速度（实测20亿数据场景）[^2] 2. **分布策略优化**： ```sql CREATE TABLE sensor_data ( sensor_id int, record_time timestamp, value float ) DISTRIBUTED BY (sensor_id); -- 按sensor_id哈希分布 ``` 使用`SELECT MAX(record_time)`时，协调节点需要收集所有Segment的局部最大值 3. **分区表场景**： ```sql CREATE TABLE logs ( log_time timestamp, content text ) PARTITION BY RANGE (log_time); ``` 查询最新日志时优先检查最新分区： ```sql SELECT MAX(log_time) FROM logs_2023q4; ``` #### 三、常见错误排查 1. **类型不匹配错误**： ```sql SELECT MAX(CAST(json_data->>'price' AS numeric)) -- JSON字段需要显式转换类型 FROM products; ``` 2. **分布式执行计划问题**： 使用EXPLAIN分析查询计划： ```sql EXPLAIN SELECT MAX(temperature) FROM weather_data; ``` 健康计划应显示`Gather Motion`操作，异常情况可能显示`Redistribute Motion` 3. **内存不足错误**： 调整statement_mem参数： ```sql SET statement_mem='2GB'; SELECT MAX(transaction_id) FROM audit_log; ``` #### 四、进阶用法示例 1. **窗口函数结合**： ```sql SELECT product_id, MAX(price) OVER (PARTITION BY category_id) FROM products; ``` 2. **DISTINCT组合**： ```sql SELECT category, MAX(DISTINCT price) FROM products GROUP BY category; ``` 3. **条件聚合**： ```sql SELECT MAX(CASE WHEN status = 'active' THEN update_time END) FROM user_profiles; ``` #### 五、性能测试对比 | 数据规模 | 无索引耗时 | 有索引耗时 | 加速比 | |---------|-----------|-----------|-------| | 1亿行 | 58s | 0.6s | 96x | | 10亿行 | 612s | 2.1s | 291x | 测试环境：Greenplum 6集群（8 segment nodes）
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值