-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add fuzz testing for UTF8 LIKE pruning #13253
base: main
Are you sure you want to change the base?
Conversation
/// Tests for `LIKE` with truncated statistics to validate incrementing logic | ||
/// | ||
/// Create several 2 row batches and ensure that `LIKE` with the min and max value | ||
/// are correctly pruned even when the "statistics" are trunated. | ||
#[test] | ||
fn test_prune_like_truncated_statistics() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's also worth having tests for =
and maybe other operators, it was not immediately obvious to me that there wasn't a bug with those as well.
// Make 2 row random UTF-8 strings | ||
let mut rng = thread_rng(); | ||
let statistics = TestPruningStatistics::new(&mut rng, 100); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I imagine a lot of the bugs are going to be around edge cases: empty strings, non-ascii characters, etc. Is there any way we could inject those into the randomness? Maybe what we need here more than random fuzzing is a matrix style test:
- Generate N full length values, including some random ones?
- Arrange them into row groups in multiple orders, of multiple sizes
- Truncate the stats to lengths between 1 and large
And make sure the results with and without pruning match?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
THis is a good idea
Draft as it builds on #12978
Which issue does this PR close?
Part of #507
Rationale for this change
While working on #12978 with @adriangb and @findepi I am having nightmares of subtle bugs introduced with truncated statistics
What changes are included in this PR?
Fuzz tests for pruning with truncated statistics / prefix values
Are these changes tested?
It is only tests
cargo test --test fuzz -- pruning
Are there any user-facing changes?
No, tests only