Speed up pruner by adding a partially covering index

[mkysel]

Our pruner in us-east-2 dev was failing. The prune query was taking more than 5ish minutes.

The index creation here is the same as in 00016 and does not use concurrently, which might eventually become a problem. But so far its the pattern, so I am keeping it going.

[graphite-app]

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• Queue - adds this PR to the back of the merge queue
• Hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[macroscopeapp]

Create a partial covering index gateway_envelopes_expiry_idx on gateway_envelopes(expiry) including originator_node_id and originator_sequence_id with statement_timeout set to 0 to speed up pruning

This change adds migrations to manage a partial covering index on gateway_envelopes. The up migration disables session statement_timeout and creates gateway_envelopes_expiry_idx on gateway_envelopes(expiry) including originator_node_id and originator_sequence_id for rows where expiry IS NOT NULL. The down migration drops the index if it exists.

• Add up migration to create partial covering index with statement_timeout=0 in 00017_prune_index.up.sql
• Add down migration to drop the index if present in 00017_prune_index.down.sql

📍Where to Start

Start with the up migration in 00017_prune_index.up.sql to review the index definition and session settings.

---

Macroscope summarized 116129a.

[fbac]

Should we create this concurrently?

[mkysel]

definitely. But I haven't had the chance to figure out how to do CONCURRENTLY. There is some setting somewhere. Will be worth investigating eventually.