* fix(studio): check job_run_details size in cron display
When cron.job_run_details grows too large (200k+ rows), loading the
cron jobs overview can timeout and affect other queries by pulling
excessive data into shared buffers.
This change:
- Estimates table size using pg_stat before fetching cron jobs data
- Shows a cleanup notice when the table exceeds the threshold
- Provides batched deletion using ctid ranges to avoid buffer pollution
- Allows scheduling an automated daily cleanup cron job
- Handles timeout errors gracefully with a "suspected overflow" state
The useCronJobsData hook now returns a discriminated union status that
tracks loading, estimate-error, overflow-confirmed, overflow-suspected,
and ready states, allowing the UI to respond appropriately to each case.
* fix(studio): use index when querying cron.job_run_details
cron.job_run_details is only indexed by runid, not by start_time. Change
the query to use the runid index (which gives the same result, since
runid is auto-incrementing).
The global storage size validation depends on an unpaginated buckets
query to determine whether it is lower than any individual bucket's
cutoff. This causes a problem for users with tens of thousands of
buckets.
There's a bit of a UX/performance problem here, because in order to
determine whether any bucket's `file_size_limit` exceeds the global
setting, we need to get the max `file_size_limit` of `storage.buckets`
-- however, that column is not indexed.
My workaround is:
- Below a certain threshold (10,000) buckets, the query for max
`file_size_limit` is automatically run on form submit.
- Above that threshold, the user must confirm whether they want to run
the query. They're still allowed to change the storage config without
running it -- this does open a loophole where they can have a global
storage setting lower than an individual bucket's file size limit, but
though this is a potentially confusing situation, it's not strictly an
error.
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Charis