Alena0704 commented on PR #1719: URL: https://github.com/apache/cloudberry/pull/1719#issuecomment-4427470214
> maybe the best way to fix the root cause is fixing the Sequence::pdsRequired, in my opinion, this path is an illegal path which should be pruned by pdsRequired restrition. What's more, maybe we can add restriction between CCTEReq and CCTEMap by checking the motion worker number, only when they have the same motion workers, CCTEMap::FSatisfies will return true and we will get a legal path. Prefer to the first path, it's more formal than the second which looks like a remedial plan. Thanks for the suggestion. Agreed that pruning during search is cleaner than a post-hoc fallback, but both proposed variants only cover part of the cases. Sequence::PdsRequired already does the right thing on its own boundary: when the first child derives Replicated, it requests EdtReplicated on the second child. The issue is that the Motion which breaks slice alignment is enforced deeper inside the second child's subtree (typically a Gather under a scalar subquery) - so it lands in a different slice than the Producer, and that's not constrained by the spec Sequence sets at its own boundary. CCTEMap::FSatisfies + motion worker count - at FSatisfies time we only know the kind of distribution from CDistributionSpec. Concrete slice ids don't exist yet - they get assigned later, when Motion nodes are enforced, and because of this we can't catch the original cross-slice problem. The current walker-based approach feels more general and reliable to me, because it catches the cross-slice problem regardless of which Motion produced it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
