The following bug has been logged on the website:
Bug reference: 18206
Logged by: Daniel Migowski
Email address: dmigowski@ikoffice.de
PostgreSQL version: 15.5
Operating system: Windows + Linux
Description:
I have a table with some columns id and a to z and these two queries have
drastically different runtimes.
select count(id) FROM testtable t WHERE t.z IS NULL; (35% slower than
WHERE t.a IS NULL)
select count(id) FROM testtable t WHERE t.a IS NULL;
This just screems like somewhere PostgreSQL is iterating over fields over
and over again without assigning field indexes to the literals.
Please create a test table this way:
drop table if exists testtable cascade;
SELECT generate_series::int4 as id, null::int4 a, null::int4 b,
null::int4 c, null::int4 d, null::int4 e, null::int4 f, null::int4 g,
null::int4 h, null::int4 i, null::int4 j,
null::int4 k, null::int4 l, null::int4 m, null::int4 n, null::int4 o,
null::int4 p, null::int4 q, null::int4 r,
null::int4 s, null::int4 t, null::int4 u, null::int4 v, null::int4 w,
null::int4 x, null::int4 y, null::int4 z
into testtable
FROM generate_series(1,6000000,1);
Doesn't matters if parallel query is used, can also be deactivated. But it's
strange to see that reordering the physical column layout can have such a
large effect on the tables.