Daan MeijerandClaude Fable 5.1
4d46db291e
The first run scanned the 58M-row pending table on the HDD once per 6-hour window and starved the prober and the batch store. Now one scan classes the finished rows and seeds the record, and the waiting rows go by windows of created_at through their index. The prober's start puts a previous run's claims back with a status scan of the same table, 20+ minutes after every deploy: a partial index on the taken rows (migration 6900) makes it instant. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
21 lines
681 B
TypeScript
21 lines
681 B
TypeScript
import { BaseSchema } from '@adonisjs/lucid/schema'
|
|
|
|
/**
|
|
* The prober's start puts a previous run's claims back (PendingLadder.release: status 9 → 0), which scanned the
|
|
* 58M-row pending table on the HDD for 20+ minutes after every deploy (LOG.md (130)): a partial index on the few
|
|
* taken rows makes it instant.
|
|
*/
|
|
export default class extends BaseSchema {
|
|
static disableTransactions = true
|
|
|
|
async up() {
|
|
this.schema.raw(
|
|
`CREATE INDEX CONCURRENTLY IF NOT EXISTS pending_releases_taken_idx ON pending_releases (release_key) WHERE status = 9`
|
|
)
|
|
}
|
|
|
|
async down() {
|
|
this.schema.raw(`DROP INDEX CONCURRENTLY IF EXISTS pending_releases_taken_idx`)
|
|
}
|
|
}
|