Re: BUG #16840: Rows not found in table partitioned by hash when not all partitions exists

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #16840: Rows not found in table partitioned by hash when not all partitions exists
Дата
Msg-id 2407555.1611770914@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #16840: Rows not found in table partitioned by hash when not all partitions exists  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #16840: Rows not found in table partitioned by hash when not all partitions exists  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes:
> CREATE TABLE dir (
>    id SERIAL,
>    volume_id BIGINT,
>    path TEXT
> ) PARTITION BY HASH (volume_id);
> CREATE TABLE  dir_part_2 PARTITION OF dir FOR VALUES WITH (modulus 3,
> remainder 2);
> SELECT * FROM dir WHERE volume_id=1 AND (path='abc' OR path='def')  --
> returns 0 rows - NOT OK!

Hmm, seems to be a case of faulty partition exclusion, because the
plan isn't scanning anything:

=# explain SELECT * FROM dir WHERE volume_id=1 AND (path='abc' OR path='def');
                QUERY PLAN                
------------------------------------------
 Result  (cost=0.00..0.00 rows=0 width=0)
   One-Time Filter: false
(2 rows)

Probably the reason we'd not noticed is that an incomplete set of
hash partitions isn't a very useful situation: if you don't
populate all of the partitions, you risk unexpected insertion
failures, since you really shouldn't be assuming which partition
any given key value will map into.  Still, it's clearly a bug.
Thanks for the report!

            regards, tom lane



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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Inconsistent application of [, ...] in documentation
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #16794: BEFORE UPDATE FOR EACH ROW triggers on partitioned tables can break tuple moving UPDATEs