The following bug has been logged on the website:
Bug reference: 17885
Logged by: Sergei Kornilov
Email address: sk@zsrv.org
PostgreSQL version: 15.2
Operating system: linux
Description:
Hello
Today I was looking for the problem of one slow query and minimized the
example to such case:
create table part_test (range bigint, col_a bigint, col_b bigint) partition
by range (range);
select format($$create table part_test_%s partition of part_test for values
from ( %L ) to ( %L )$$, lpad(i::text, 3, '0'), (i-1)*1e6, i*1e6) from
generate_series(1,49) as i;
\gexec
explain (analyze,buffers) select * from part_test where col_a = 123
and col_b not in (
0, 1, 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15,16,17,18,19,
20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,
40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,
60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,
80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99
);
(50 partitions and 100 elements "in")
With this query I am getting abnormally high planning time:
Planning Time: 239.610 ms
Execution Time: 0.324 ms
Increasing the number of partitions or size of "not in" list further
increases planning time. Reproduced on today's HEAD 16dev too. I found time
is wasted somewhere in relation_excluded_by_constraints. If I disable
constraint_exclusion completely, then the planning time drops to a few
milliseconds.
regards, Sergei
