- Notifications
You must be signed in to change notification settings - Fork5
Commitf39d57b
committed
Rejigger mergejoin logic so that a tuple with a null in the first merge column
is treated like end-of-input, if nulls sort last in that column and we are notdoing outer-join filling for that input. In such a case, the tuple cannotjoin to anything from the other input (because we assume mergejoinableoperators are strict), and neither can any tuple following it in the sortorder. If we're not interested in doing outer-join filling we can justpretend the tuple and its successors aren't there at all. This can save agreat deal of time in situations where there are many nulls in the joincolumn, as in a recent example from Scott Marlowe. Also, since the plannertends to not count nulls in its mergejoin scan selectivity estimates, thisis an important fix to make the runtime behavior more like the estimate.I regard this as an omission in the patch I wrote years ago to teach mergejointhat tuples containing nulls aren't joinable, so I'm back-patching it. Butonly to 8.3 --- in older versions, we didn't have a solid notion of whethernulls sort high or low, so attempting to apply this optimization could breakthings.1 parentede5072 commitf39d57b
1 file changed
+268
-233
lines changed0 commit comments
Comments
(0)