Closed steve-chavez closed 8 months ago
For this I think logging stats of the schema cache load will help. Like so:
06/Feb/2024:23:33:22 -0500: Starting PostgREST 11.2.0 (eaa1d81)...
06/Feb/2024:23:33:22 -0500: Attempting to connect to the database...
06/Feb/2024:23:33:22 -0500: Connection successful
06/Feb/2024:23:33:22 -0500: Admin server listening on port 3001
06/Feb/2024:23:33:22 -0500: Listening on port 3000
06/Feb/2024:23:33:22 -0500: Listening for notifications on the pgrst channel
06/Feb/2024:23:33:22 -0500: Config reloaded
06/Feb/2024:23:33:22 -0500: Schema cache queried in 17.4 milliseconds
06/Feb/2024:23:33:22 -0500: Relations: 264, Relationships: 221, Routines: 140, Domain Representations: 15, Media Type Handlers: 43
06/Feb/2024:23:33:22 -0500: Schema cache loaded in 12.0 milliseconds
That will help users infer if the schema cache queries are taking longer over time. By counting the schema cache items, the user can also infer if the queries are taking longer because of their schema complexity or pg_catalog bloating.
I'll also put a mention about pg_catalog bloating on the docs.
I wonder if it'd be a good idea to also include a "bloat" metric, like:
06/Feb/2024:23:33:22 -0500: Relations: 264, .. Catalog Bloat: 281
This can be obtained with:
SELECT sum(n_dead_tup) FROM pg_stat_all_tables where schemaname = 'pg_catalog';
-[ RECORD 1 ]
sum | 281
If the number is high or getting higher then that would indicate that the schema cache queries are or will be slow.
It seems like a stretch including that metric in the schema cache. Will just document the pg_catalog bloat contributing to the query slowdown.
Problem
Having a bloated
pg_depend
:Makes the tablesSqlQuery slow:
Execution Time: 4657.589 ms
Same output but on depesz: https://explain.depesz.com/s/7ZKv#html. The main problem is the Index Scan on
pg_depend_reference_index
.This is a problem when
statement_timeout
is set low forauthenticator
, which leads to a loop of errors like:Also note that for this particular case, vacuum is not working on
pg_depend
; this is what's causing the bloat.Solution?
Though the fix here is to clear whatever is holding the vacuum on
pg_depend
(in this particular case apg_drop_replication_slot()
solved it), could we show a better error message so the problem with the schema cache is obvious?