Re: Unexpected (wrong?) result querying boolean partitioned table with NULL partition
David Kimura <david.g.kimura@gmail.com>
From: David Kimura <david.g.kimura@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2023-04-12T16:13:26Z
Lists: pgsql-hackers
On Wed, Apr 12, 2023 at 4:13 AM David Rowley <dgrowleyml@gmail.com> wrote: > On Wed, 12 Apr 2023 at 22:13, David Kimura <david.g.kimura@gmail.com> wrote: > > Is it fair to assume that, given the same data, a partitioned table should > > return the same results as a non-partitioned table? > > Yes, and also the same as when enable_partition_pruning is set to off. Thanks for making me aware of that GUC. > > One idea is to use the negation operator for IS_NOT_(true|false) (i.e. > > BooleanNotEqualOperator instead of BooleanEqualOperator). But besides > > presumably being a more expensive operation, not equal is not part of the btree > > opfamily for bool_ops. So, seems like that won't really fit into the current > > partition pruning framework. > > There's already code to effectively handle <> operators. Just the > PartClauseInfo.op_is_ne needs to be set to true. > get_matching_list_bounds() then handles that by taking the inverse of > the partitions matching the equality operator. Ah, I missed that when I first tried to implement that approach. Indeed, this seems cleaner. Also, the domain space for boolean partitions is very small, so any added cost for searching not equal seems negligible. Thanks, David
Commits
-
Fix incorrect partition pruning logic for boolean partitioned tables
- 1c19e2863994 11.20 landed
- 0b2e77ce288d 12.15 landed
- 6848f0c67c60 13.11 landed
- ae85fb828c07 14.8 landed
- 0c09160e113f 15.3 landed
- e0693faf797f 16.0 landed