The following bug has been logged on the website:
Bug reference: 16249
Logged by: Matthias vd Meent
Email address: boekewurm+postgres@gmail.com
PostgreSQL version: 11.5
Operating system: Debian Stretch, RDS
Description:
CREATE TABLE test (num bigint UNIQUE PRIMARY KEY) PARTITION BY RANGE
(num);
CREATE TABLE test_100 PARTITION OF test FOR VALUES FROM (0) TO (100);
CREATE TABLE test_200 PARTITION OF test FOR VALUES FROM (100) TO (200);
INSERT INTO test SELECT * FROM generate_series(0, 199, 1)
-- sql console 1
BEGIN;
REINDEX TABLE test_100;
-- sql console 2
BEGIN;
/* the following queries return immediately */
SELECT * FROM test_200 WHERE num between 101 AND 105;
\d+ test
LOCK TABLE test IN ACCESS SHARE MODE;
/* this does not return a result immediately: it blocks in the planning */
SELECT * FROM test WHERE num BETWEEN 101 AND 105;
/*
When we finally commit / rollback in window 1, we get the following
result:
QUERY PLAN
---------------------------------------------------------------------------------------------------------------
Append (cost=0.00..2.52 rows=5 width=8) (actual time=0.007..0.014 rows=5
loops=1)
-> Seq Scan on public.test_200 (cost=0.00..2.50 rows=5 width=8) (actual
time=0.007..0.013 rows=5 loops=1)
Output: test_200.num
Filter: ((test_200.num >= 101) AND (test_200.num <= 105))
Rows Removed by Filter: 95
Planning Time: 80872.004 ms
Execution Time: 0.026 ms
(7 rows)
*/
In my humble opinion, this query should not be blocked during planning, as
the partition can be pruned directly from the plan with the partition
information that is available from the parent table: Partition information
can be updated when the partition is locked, but through the parent
partitioned table.
Examples have been tested on both Debian and Amazon RDS.
With regards,
Matthias
