问题:
查询语句select count(*) from 表名执行时间超48小时,session_stat显示WAIT IO,磁盘不忙。帮忙分析问题
openGauss版本:2.0.0
相关图片:
Hey @enmo_limengjie, Welcome to openGauss Community.
All of the projects in openGauss Community are maintained by @opengauss_bot.
That means the developers can comment below every pull request or issue to trigger Bot Commands.
Please follow instructions at Here to find the details.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。
Hi @enmo_limengjie, please use the command /sig xxx to add a SIG label to this issue.
For example: /sig sqlengine or /sig storageengine or /sig om or /sig ai and so on.
You can find more SIG labels from Here.
If you have no idea about that, please contact with @xiangxinyong , @zhangxubo .
@enmo_limengjie
你好,想问下这个问题有没有多点的信息? 比如什么时候下出现的, 表的个数、大小之类的? 另外这个问题必现吗 或者有重现方法吗?
直接select count(*) 其实连表都不用扫描,不太涉及到IO的操作,应该耗时很短才对
图片中有详细描述,
语句:select /*+ indexonlyscan(table_name index_name) */ from table_name
表的大小:29GB,索引大小:3872MB
1)indexonlyscan超48小时未执行完毕:已解决,原因为没有vm文件,已经通过vacuum机制重新生成vm文件 。
2)引入新的问题:没有回表情况下, indexonlyscan 性能慢于 seqscan, seqscan 扫描全表为 10分钟左右,indexonlyscan 扫描全表为 2-3 小时左右
通过测试,
1)索引的不连续对于范围扫描有一定的影响。参考下图(下图中是否连续指的索引的叶子节点,未特殊标明的走的是bitmapscan)
2)对于连续的索引,走了错误的执行计划。数据量为35%时,analyze后,默认走的bitmapscan,但加hint发现走seqscan更快
能否打开如下两个开关看下bitmapscan 和 seqscan的路径代价?
log_min_messages = debug5
logging_module = 'on(OPT_JOIN)'
代价在data 目录下的pg_log/postgresqlxxxx.log 下,如下所示:
登录 后才可以发表评论