New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential Issue for Estimated Rows #88455
Comments
Hello, I am Blathers. I am here to help you get the issue triaged. Hoot - a bug! Though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here. I was unable to automatically find someone to ping. If we have not gotten back to your issue within a few business days, you can try the following:
🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan. |
Previously, an `OR` expression with tight constraints would have its selecitivy applied in `applyFilters` as expected, without incrementing `numUnappliedConjuncts`. However, joins call into `selectivityFromOredEquivalencies`, which would then increment `numUnappliedConjuncts` for that `OR` if the disjuncts weren't all conjunctions of equalities. This caused an additional factor of `1/3` (`memo.unknownFilterSelectivity`) to be applied to the join row count estimate. This commit modifies `selectivityFromOredEquivalencies` to avoid incrementing `numUnappliedConjuncts` for `OR` conditions with tight constraints. This prevents the double-counting behavior. This commit also removes a few `FiltersItem` copies from loops. Fixes cockroachdb#88455 Release note: None
Thanks for opening this issue! Looks like we were doing some double-counting when estimating the selectivity of |
Thanks for your prompt reply! I'm glad we can help CockroachDB get better! |
88555: opt: don't double count OR selectivity for joins r=DrewKimball a=DrewKimball Previously, an `OR` expression with tight constraints would have its selecitivy applied in `applyFilters` as expected, without incrementing `numUnappliedConjuncts`. However, joins call into `selectivityFromOredEquivalencies`, which would then increment `numUnappliedConjuncts` for that `OR` if the disjuncts weren't all conjunctions of equalities. This caused an additional factor of `1/3` (`memo.unknownFilterSelectivity`) to be applied to the join row count estimate. This commit modifies `selectivityFromOredEquivalencies` to avoid incrementing `numUnappliedConjuncts` for `OR` conditions with tight constraints. This prevents the double-counting behavior. This commit also removes a few `FiltersItem` copies from loops. Fixes #88455 Release note: None 89050: rowexec: fix usage of the shared "single datum" acc in windower r=yuzefovich a=yuzefovich This commit fixes the usage of the shared "single datum agg mem account" by the window builtins. Previously, we were updating the eval context with the memory account after the builtins were constructed. The impact of the bug on its own is pretty minor (namely that we could reserve more memory than necessary - the initial allocation is 10KiB), but I have some other changes brewing which make it more important to be precise about the attribution of the memory allocations. Release note: None Co-authored-by: DrewKimball <drewk@cockroachlabs.com> Co-authored-by: Yahor Yuzefovich <yahor@cockroachlabs.com>
Describe the problem
The estimated row count of the first SELECT statement may be far from real number.
To Reproduce
Expected behavior
The first and second SELECT statements are semantic equivalents, so I think both statements should have the same number of estimated rows? They don't in fact.
As a reference, I also rewrite
LEFT JOIN
toINNER JOIN
and get the third SELECT statement. In my understanding, theINNER JOIN
should have no greater estimated row count thanLEFT JOIN
.Therefore, I suspect there is an issue for the estimated rows of the first SELECT statement.
Environment:
cockroach sql
]Additional context
Although the estimated row count is an approximate number, I think this may be a potential issue which may impact the query optimization. I hope it would provide valuable information. Looking forward your reply!
Jira issue: CRDB-19831
The text was updated successfully, but these errors were encountered: