If we convert it to doing it based on each authority, it uses the index, e.g.
isb_1=# explain analyze select count(*) from thing where authority_id='SESAR';
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=1615751.78..1615751.79 rows=1 width=8) (actual time=2463.386..2470.974 rows=1 loops=1)
-> Gather (cost=1615751.56..1615751.77 rows=2 width=8) (actual time=2463.232..2470.958 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Partial Aggregate (cost=1614751.56..1614751.57 rows=1 width=8) (actual time=2434.421..2434.425 rows=1 loops=3)
-> Parallel Index Only Scan using resolved_status_authority_id_idx on thing (cost=0.43..1609921.66 rows=1931960 width=0) (actual time=8.436..1272.184 rows=1562795 loops=3)
Index Cond: (authority_id = 'SESAR'::text)
Heap Fetches: 82983
Planning Time: 0.193 ms
JIT:
Functions: 11
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 1.610 ms, Inlining 142.466 ms, Optimization 41.098 ms, Emission 27.292 ms, Total 212.466 ms
Execution Time: 2471.750 ms
(14 rows)
We shoud probably break it up by authority to avoid overtaxing the database. A short-term fix is to run the query once an hour instead of once a minute.
We've seen postgresql have a number of problems. It seems to boil down to a summary query running incredibly slowly:
That's ~69 sec for that query. The inner part of the loop is doing a sequential scan:
If we convert it to doing it based on each authority, it uses the index, e.g.
We shoud probably break it up by authority to avoid overtaxing the database. A short-term fix is to run the query once an hour instead of once a minute.