写回答
-
推荐回答这个可以分两部分看，第一是Join下推本身算法的性能，这个依赖于Plan Cache。首先我们会对执行计划做一个参数化，然后根据参数化的SQL，当判定这个查询能够下推，那它后面所有的不同参数的查询到来之后，就可以直接从Plan Cache里面读出来，那就可以下推。
接下来可能的问题是，当把Join下推到DN上执行，会不会性能就更好？这个对于TP来说的话，大体上是成立的，因为降低网络开销，肯定带来一个RT的缩短。但是对于AP类的查询，有的时候不一定。因为DN的计算资源肯定没有CN多，有的时候把一些AP类的Join下推下去是不太合理的。所以在做这个事情的时候，也有基于这个CBO的判断，CBO本身的代价模型里会去估算一下DN执行这个Join的代价和CN执行这个Join的不同代价。如果下推到DN上代价更高的话，那就会考虑把这个数据拉到CN上来做。
所以下推性能问题，在TP场景下大多数时候下推都是可以的。如果下推性能不好，也可以通过CBO识别出来，将数据拉回到CN上执行。
以上内容摘自《PolarDB-X 从入门到实战》电子书，点击https://developer.aliyun.com/ebook/download/7674可下载完整版
2022-07-12 15:44:07赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
PolarDB 分布式版 (PolarDB for Xscale，简称“PolarDB-X”) 是阿里云自主设计研发的高性能云原生分布式数据库产品，为用户提供高吞吐、大存储、低延时、易扩展和超高可用的云时代数据库服务。
