On 4 April 2018 at 11:22, David Rowley <david.row...@2ndquadrant.com> wrote: > On 4 April 2018 at 09:47, David Rowley <david.row...@2ndquadrant.com> wrote: >> I think it would be better to just have special handling in >> get_matching_list_bound so that it knows it's performing <> >> elimination. I'd thought about passing some other opstrategy but the >> only safe one I thought to use was InvalidStrategy, which is already >> used by NULL handling. > > I'm currently working up a patch to do this the way I think is best. > > I'll submit it soon and we can review and get your thoughts on it.
I've attached a rough cut version of what I think is a good solution for this. It's based on v46, not your latest v47, sorry. This makes get_matching_list_bounds() aware that it's performing the not-equal pruning via the opstrategy which allows it to not return all partitions when there are no values in this case. Instead, we return the NULL partition, so that we later invert that and return everything apart from the NULL partition. A strict clause will allow us that much, even if we can't get the actual value being compared to, at the time. There's also a bunch of other changes in there: 1. Adding missing step_id in copyfuncs.c 2. Simplified including the default partition in a bunch of cases. 3. Made it so scan_default and scan_null are only ever set to true if there's a partition for that. 4. Changed get_matching_*_bounds to return the entire result struct instead of the Bitmapset and pass the remaining bool values back through params. I didn't really like how you'd change this to pass all the bool flags back as params. There's a perfectly good struct there to provide the entire result in a single return value. I know you've disagreed with this already, so would be nice to get a 3rd opinion. 5. Rename get_matching_hash_bound to get_matching_hash_bounds. The LIST and RANGE version of this function both had a plural name. I didn't see any reason for the hash case to be different. Let me know what you think. I've patched the run-time pruning v18 against this and it now passes regression. I need to do a bit more testing on this to ensure it works for all cases, but thought I'd send now as I suspect you're currently around to look. There might be another issue with the patch too, but I'll send a separate email about that. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
v46_fixes_drowley.patch
Description: Binary data