Tim Armstrong has posted comments on this change. ( http://gerrit.cloudera.org:8080/12535 )
Change subject: IMPALA-8014: Revise FK/PK cardinality estimation ...................................................................... Patch Set 5: I've been meaning to make some time to look at this. I think my high-level concern is about potential regressions (i.e. where we were wrong for the right reasons). I know you've argued against having a flag for everything because of the configuration space, testing and code complexity problems, but I wonder if there's a way we can guard against the worst issues. E.g. can we factor out the cardinality code into a strategy class with a simple interface to encapsulate the different versions of the logic? Can we limit the configuration space by using something coarser-grained than planner versioning, e.g. have a planner "epoch" that is incremented for a group of significant planner changes. Definitely don't want to be stuck being overly conservative with preserving semi-broken logic, but it would be good to mitigate the risk if it can be done with reasonable effort. -- To view, visit http://gerrit.cloudera.org:8080/12535 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Id0db82564596b0a9271b89b8e3f7a3cf92d306da Gerrit-Change-Number: 12535 Gerrit-PatchSet: 5 Gerrit-Owner: Paul Rogers <prog...@cloudera.com> Gerrit-Reviewer: Bharath Vissapragada <bhara...@cloudera.com> Gerrit-Reviewer: Impala Public Jenkins <impala-public-jenk...@cloudera.com> Gerrit-Reviewer: Paul Rogers <prog...@cloudera.com> Gerrit-Reviewer: Tim Armstrong <tarmstr...@cloudera.com> Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-Comment-Date: Wed, 03 Apr 2019 00:01:21 +0000 Gerrit-HasComments: No
