Avoid a case where the planner was erroneously dropping predicates#3965
Conversation
79c4b37 to
3911001
Compare
97d21e5 to
ddd955b
Compare
cbb9a3e to
5ade72f
Compare
… in the compaensation as needed Validate behavior in new query test, as well as in more purpose built unit tests.
a12ddf3 to
db34094
Compare
| Verify.verify(isEquality() ^ isInequality()); | ||
| Verify.verify(that.isEquality() ^ that.isInequality()); |
There was a problem hiding this comment.
A side observation related to the getRangeType() comment below — I wonder whether we should just check getRangeType() here as well. What happens if one of the two is isEmpty()? There could be another bug lurking here.
There was a problem hiding this comment.
It's possible... I'd rather we do this in a separate PR, though, as we're kind of far afield from the core bug fix at this point
alecgrieser
left a comment
There was a problem hiding this comment.
I've addressed some of (but not all of) the original comments. This mainly has involved doing additional refactoring/method extraction. I'm curious if (1) this looks more readable to you and (2) if the extractions look correct. I think there is one issue that I'm still not sure about, which is the thing you mentioned about basing the compensation off of different base predicates in different paths, and I'm still not sure if that was just an error on my part or not. In the new code, they now share a common function for that, so they're basing their compensation off of the same predicate
alecgrieser
left a comment
There was a problem hiding this comment.
I've merged in some recent metrics changes and then resolved some additional comments to try and make the code a bit more apparent. There are a few remaining that I'll take a look at in a bit
📊 Metrics Diff Analysis ReportSummary
ℹ️ About this analysisThis automated analysis compares query planner metrics between the base branch and this PR. It categorizes changes into:
The last category in particular may indicate planner regressions that should be investigated. New QueriesCount of new queries by file:
Dropped QueriesThe following queries with metrics were removed:
This list has been truncated. There is 1 remaining dropped queries. The reviewer should double check that these queries were removed intentionally to avoid a loss of coverage. Plan and Metrics ChangedThese queries experienced both plan and metrics changes. This generally indicates that there was some planner change Total: 16 queries Statistical Summary (Plan and Metrics Changed)
Significant Regressions (Plan and Metrics Changed)There was 1 outlier detected. Outlier queries have a significant regression in at least one field. Statistically, this represents either an increase of more than two standard deviations above the mean or a large absolute increase (e.g., 100).
Minor Changes (Plan and Metrics Changed)In addition, there were 15 queries with minor changes. |
alecgrieser
left a comment
There was a problem hiding this comment.
I think I've responded to everything now, though for some of them, I've commented rather than make a code change
| Verify.verify(isEquality() ^ isInequality()); | ||
| Verify.verify(that.isEquality() ^ that.isInequality()); |
There was a problem hiding this comment.
It's possible... I'd rather we do this in a separate PR, though, as we're kind of far afield from the core bug fix at this point
There was a case in
RangeConstraints.asComparisonRangewhere the process of merging different comparison ranges could result in predicates being dropped. The fundamental error was that there is a function,merge, which merges a comparison into a comparison range. However, if the comparison can't be successfully merged, then it will be added to a residual comparison list. But theasComparisonRangefunction was ignoring those predicates entirely.This modifies the method so that it collects the ranges rather than dropping them. It then also modifies the compensation function so that if there are residual predicates, we are sure to generate a predicate for it.
This fixes #3950.