While replaying our production workload we have found Postgres spending a lot of time inside TimescaleDB planner. The planner itself need an information about whether a table involved is a TimescaleDB hypertable. So planner need an access to TimescaleDB internal metainformation tables. This planner access become extremely slow when you have a lot of tables involved and you are beyond fast-path lock limit
This humble example makes only 2330 tps on REL_15_STABLE but 27041tps on patched version with 64 slots for fast-path locks. \set bid random(1,1000) BEGIN; select bbalance from pgbench_branches where bid = :bid UNION select bbalance from pgbench_branches2 where bid = :bid UNION select bbalance from pgbench_branches3 where bid = :bid UNION select bbalance from pgbench_branches4 where bid = :bid UNION select bbalance from pgbench_branches5 where bid = :bid UNION select bbalance from pgbench_branches6 where bid = :bid UNION select bbalance from pgbench_branches7 where bid = :bid UNION select bbalance from pgbench_branches8 where bid = :bid UNION select bbalance from pgbench_branches9 where bid = :bid UNION select bbalance from pgbench_branches10 where bid = :bid UNION select bbalance from pgbench_branches11 where bid = :bid UNION select bbalance from pgbench_branches12 where bid = :bid UNION select bbalance from pgbench_branches13 where bid = :bid UNION select bbalance from pgbench_branches14 where bid = :bid UNION select bbalance from pgbench_branches15 where bid = :bid UNION select bbalance from pgbench_branches16 where bid = :bid UNION select bbalance from pgbench_branches17 where bid = :bid UNION select bbalance from pgbench_branches18 where bid = :bid UNION select bbalance from pgbench_branches19 where bid = :bid UNION select bbalance from pgbench_branches20 where bid = :bid; END; First i try to make the number of fast-path locks as a GUC parameter. But it implies a lot of changes with PGPROC structure. Next I implement it as a compile-time parameter.
