Add index for cancellation timestamp

[MartinquaXD]

Description

Simply fetching the recently updated/added orders for updating the solvable orders cache is surprisingly slow. On mainnet this takes anywhere between 250ms and 3s (resolution of the time buckets is not ideal).
This query basically has the shape SELECT fields FROM orders WHERE cancellation_timestamp > $1 OR creation_timestamp > $1 OR uid = ANY($2). When running the query with EXPLAIN ANALYZE it became apparent that creation_timestamp > $1 is very fast but cancellation_timestamp > $1 is not. It turned out there was only 1 index using cancellation_timestamp and it was in an index btree(creation_timestamp, cancellation_timestamp). This query can only be used to search orders by creation_timestamp very efficiently but not by cancellation_timestamp.

When I added an index btree(cancellation_timestamp) the query time dropped from ~150ms to ~2ms. It's not completely clear how this translates to the prod environment since my test DB ran the originally query significantly faster than the prod replica but a speed up of 75x will certainly not hurt.

Changes

• removed unused index
• added useful one
• updated DB readme with new and previously missing indexex

How to test

manual tests on a cloned prod db

[github-actions]

Reminder: Please update the DB Readme and comment whether migrations are reversible (include rollback scripts if applicable).

• If creating new tables, update the tables list.
• When adding a new index, consider using CREATE INDEX CONCURRENTLY for tables involved in the critical execution path.
• For breaking changes, remember that during rollout k8s starts the new autopilot, runs the Flyway migration, and only then shuts down the old pod. That overlap means the previous version can still be processing requests on the migrated schema, so make it compatible first and ship the breaking DB change in the following release.

---

Caused by:

• database/sql/V096__update_order_timestamp_indexes.sql
• database/sql/v097__drop_old_cancellation_index.sql

[squadgazzz]

LGTM. If we still encounter issues with this query, we should probably start looking into restructuring the orders table.

[ahhda]

/gemini review

[ahhda]

@gemini-code-assist review

[gemini-code-assist]

Code Review

This pull request addresses a performance issue by adding a new index on cancellation_timestamp for the orders table, which significantly speeds up a key query. The changes also include removing a now-redundant composite index and, importantly, updating the database README to better document existing indexes. The SQL migration is correct and the documentation improvements are very welcome. I've made one suggestion to further improve the documentation accuracy.

[gemini-code-assist]

Code Review

This pull request introduces a valuable performance improvement by adding an index on cancellation_timestamp to speed up order fetching. The logic is sound and should resolve the performance issue described. I have two main points of feedback. First, and most critically, the database migration script should use CREATE INDEX CONCURRENTLY and DROP INDEX CONCURRENTLY to avoid locking the orders table in production, which could cause downtime. Second, there's a minor inconsistency in the README documentation update for an existing index. Overall, this is a great change once the migration safety is addressed.

[github-actions]

This pull request has been marked as stale because it has been inactive a while. Please update this pull request or it will be automatically closed.