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

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