Used: 438105027512, Limit: 438103947386. Mem usage has exceed the limit of single query, You can change the limit by set session variable exec_mem_limit目前我设置比较这个限制的值大，还是报错超出限制，

💬 StarRocks 用户问答 功能使用相关
#402

-h还有哪一个SQL跑不出？
你最后跑的是按照我那个表结构来建表吗？

#403

我第一次发您那个-h 建表语句

#404

你们还有时间测试吗？我再整理一下发给你们 ds和h的

#405

要继续的，麻烦您在帮忙看看，主要是-h，我记的上个礼拜咱们拉您这边研发看那个sql ，目前有进展吗

#406

还是从表结构优化吧，那个没有通过参数就能优化的方案。

#407

嗯嗯好的，那我们从建表语句上优化吧，还有就是数据我问一下，目前没有办法调整，通过官网上下载的生成数据程序

#408

生成数据程序我不是负责这一块，要读一下源代码改一下，先兼容生成数据程序从建表语句优化，这样改动较小。

#409

对，是的，先按照您提供的，我看看sql 怎么拆分一下sql是不是会更好一些

#410

先优化完表结构能否跑出来吧，SQL也改动就对测试脱离原意了。

#411

是，您说的对，但是我们现在时间有点紧张，这两天就要交差了

#412

10t-h-final.txt (18.0 KB)
请你-h根据这个测试一下，谢谢！

#413

参数优化
2.3.0
enable_pipeline_engine=true
parallel_fragment_exec_instance_num=1
pipeline_dop=64
exec_mem_limit = 515396075520

be.conf
mem_limit=95%
disable_storage_page_cache=false
storage_page_cache_limit= 64G

#414

嗯嗯好的，感谢，麻烦问一下您这个-h 的测试 你们最大测试过多大量级别的

#415

10tds第三版本-final.txt (33.2 KB)

#416

ds和h都是1TB

#417

麻烦请教一下，最大的那个表，lineitem DISTRIBUTED BY HASH(l_orderkey) ，您选择l_orderkey 均匀分布数据的原因是什么呢？

#418

主要是针对Colocate join。如果这里设置多个值，会导致Colocate join失效。

#419

lineitem和orders之间的Colocate join

#420

我觉的数据分布key选择少了，会导致效率下降

#421

两个上百亿的表 shuffle join 就会导致内存问题，两个超大表关联colocate join是很好的解决方案。

京ICP备2022026421号-1