tongke

密态下进行比较的开销较大，主要是通信开销打，导致耗时较长。 目前不支持 order by 的原因主要有两点： 1. order by 在密态下计算开销太大，用户拿到结果后也可以明文进行 sort 得到结果，在这种场景下是可替代的。 2. order by 暂无 CCL 约束可以覆盖。 不过这些都是实现上的考虑，都是可以解决的，未来会考虑支持 order by。

抱歉，因为计划还未实施，暂无更多的信息透出。

Hi @daydayuphere 0.6.0 版本已支持在 kuscia 里运行 SCQL

可以补充一下，测试的机器配置是怎样的吗，以及网络带宽和延迟？

在这种数据规模，以及机器和网络情况下，运行十几个小时没有响应是不正常的。 可以提供更多的信息，以方便我们复现下问题吗？ BTW，上面的截图是其中一方的日志，另一方的日志方便也贴一下吗？

不加这个配置，这个值就是 16，改成 0 后，会使用 yacl 的默认配置，值为 10

在局域网环境下，我们一直都是默认 16 跑没出现过这个问题。我怀疑是内核参数的问题，导致某个地方卡主了。 你所在的环境的操作系统，以及内核版本信息方便提供吗？

Thank you for your suggestion, we will consider supporting this feature in the future.

请进入到 engine 的容器中，用配置的 pgsql 连接串连接一下 pgsql 试下，看是否可以联通

Hi @Shareong，感谢认可～ 1. 等 vertical group by 实现到 github 上来再展开细节哈～ 抱歉不在这里展开。 2. 目前 HESum group by 用的是半同态加密，只能做 sum。求 min/max 不会走到 HESum group by 实现。如果要使用同态加密求极值，可能要用 TFHE。你这里提到的 ORE 是什么，可以展开说下吗，以及是否有相关的资料。