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

最新推荐文章于 2021-07-16 18:01:00 发布
原创 最新推荐文章于 2021-07-16 18:01:00 发布 · 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
经常php页面无响应,关于最近我的blog经常没有响应的问题
weixin_42508792的博客
03-10 339
#0 0x00007f08b8813248 in poll () from /lib64/libc.so.6#1 0x00007f08ac57a8f6 in Curl_socket_ready () from /usr/lib64/libcurl.so.4#2 0x00007f08ac571c11 in ?? () from /usr/lib64/libcurl.so.4#3 0x0000...
gdb 调试mysql_GDB 调试 Mysql 实战（二）GDB 调试打印
weixin_30801745的博客
01-26 448
背景在 https://mengkang.net/1328.html 实验中，我们通过 optimizer_trace 发现 group by 会使用 intermediate_tmp_table ，而且里面的的 row_length 是20，抱着"打破砂锅问到底"的求学精神，所以想通过 gdb 调试源码的方式看这个 row_length 为什么是20.通过 row_length 关键字，我定位到...
Greenplum闰秒故障的分析解决
泰克轱辘儿
07-17 1983
2015年7月1日上午，国家授时中心增加了7:59:60这个时间来处理闰秒问题。对于使用网络时间协议进行时钟同步的操作系统而言，实在是不应该有什么问题才对，因为即使没有这多出的一秒，系统时钟不准个几秒也是常有的事儿啊。但是部分Linux（比如RHEL 6.2 64bit）上的部分应用（比如Greenplum数据库，也包括java和mysql这些）需要读取硬件时钟和系统时钟，这二者不一致时，就跑不动
Greenplum问题定位及性能调优
Greenplum中文社区
07-16 1265
...
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的开源分布式数据库，专为数据仓库应用而设计。它...
Linux｜ libc.so.6崩溃
Java小技巧
07-09 2391
翻车现场 由于今天在安装完node之后，系统提示： 查看一下/lib64/libc.so.6是什么鬼： 由于是内网，不能在线下载依赖数据包，也没有办法把外网的数据拿过来。这时突然想到最近新申请过一台服务器，然后想着看下新申请服务器的文件版本会不会高点。 果然：（由于看着版本比较高，就想着直接拿过来用吧。） 拿过来之后当然要先备份一下现有的文件了，然后就执行了一个命令： $ mv libc.so.6 libc.so.6_20200708_bak 执行之后突然发现整个世界都不一样了：（ls、ll、dat
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 Orca 优化器目录结构
那海蓝蓝的博客
03-13 1639
├─cmake              构建相关├─data               测试数据├─libgpdbcost        代价模型│  ├─include│  │  └─gpdbcost│  └─src├─libgpopt│  ├─include         头文件│  │  └─gpopt        ...│  └─src│      ├─base        实现
Greenplum性能优化之路 --（一）分区表
jc_benben的专栏
07-10 1667
什么是分区表 分区表就是将一个大表在物理上分割成若干小表，并且整个过程对用户是透明的，也就是用户的所有操作仍然是作用在大表上，不需要关心数据实际上落在哪张小表里面。Greenplum中分区表的原理和PG一样，都是通过表继承和约束实现的。 Greenplum官方给出的分区表示例如下： partitions.jpg 与分布的区别 分布：DISTRIBUTED 分区：PARTITION Greenplum中每个表都需要有一个分布键，如果你建表的时候没有显示使用语法DISTRIBUTED.
关于linux的进程中的各个线程cpu占用情况的分析和查看
weixin_34387468的博客
12-26 708
我们常常会在新开的服搭建一个游戏的server，有时候要进行压力測试，那么怎样来看呢，一般我们会通过top命令查看各个进程的cpu和内存占用情况，获得到了我们的进程id，然后我们或许会通过pstack命令查看里边的各个线程id以及相应的线程如今正在做什么事情，分析多组数据就能够获得哪些线程里有慢操作影响了server的性能，从而得到解决方式。比方这种以组数据： [root@AY13081...
Greenplum学习笔记之二【执行计划】
weixin_41197407的博客
02-04 2452
1. 如何产生执行计划 explain和explain analyze，都可以显示执行计划 EXPLAIN ANALYZE运行语句后除了显示计划外，还有下列额外的信息： 运行该查询消耗的总时间（单位毫秒） 计划几点操作中涉及的segment数量 查询中产生最多行的segmen的segmentID以及最大行数 操作中所使用的内存 从产生最多行的segment中检索第一行所花费的时间，以及从该segment中检索所有行所花费的时间 explain和explain analyze的区别： explai
gethostbyname超时，与遇到的一些坑
weixin_34120274的博客
09-04 3321
现网有些DNS服务器质量不好，经常不返回，导致服务器在做DNS请求时经常被卡住，简单测试后发现如果服务器不返回结果，一般20+秒超时。但是如果使用alarm和signal，是不能中断系统函数的，参考了一些网络上的资料，可以设置sigsetjmp和siglongjmp来打断系统函数，并可以恢复之前的堆栈，避免发生问题。 static sigjmp_buf jmpbuf; static void al...
线程的查看以及利用gdb调试多线程
热门推荐
zhangye3017的博客
05-20 10万+
1. 线程的查看 首先创建两个线程： #include <stdio.h> #include <unistd.h> #include <pthread.h> #include <stdlib.h> #in
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、付费专栏及课程。

余额充值