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

PG Bug reporting form <noreply(at)postgresql(dot)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