Re: Unexpected (wrong?) result querying boolean partitioned table with NULL partition

Поиск
Список
Период
Сортировка
От David Kimura
Тема Re: Unexpected (wrong?) result querying boolean partitioned table with NULL partition
Дата
Msg-id CAHnPFjRbzcEZ1OOXfbBcsKR3zjJ_73tRbnfiYhwqS8NMoKVzKQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Unexpected (wrong?) result querying boolean partitioned table with NULL partition  (David Rowley <dgrowleyml@gmail.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Direct I/O
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Add two missing tests in 035_standby_logical_decoding.pl