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/V095__update_order_timestamp_indexes.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]

Thanks for adding the missing indexes to the documentation! Just a small correction: this index is on creation_timestamp in descending order.

It also looks like order_valid_to and user_valid_to indexes are for the orders table but are currently documented under order_execution. It would be great to move them here as well to make the index list for orders complete.

Suggested change

	- user_order_creation_timestamp: btree(`owner`, `creation_timestamp`)
	- user_order_creation_timestamp: btree(`owner`, `creation_timestamp` DESC)

[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.

[gemini-code-assist]

Creating and dropping indexes on a large production table like orders without the CONCURRENTLY option can cause significant downtime. CREATE INDEX (without CONCURRENTLY) takes an ACCESS EXCLUSIVE lock on the table, blocking all reads and writes until the index is built. Similarly, DROP INDEX locks the table.

To avoid this, you should use CREATE INDEX CONCURRENTLY and DROP INDEX CONCURRENTLY.

Note that CREATE INDEX CONCURRENTLY cannot be run inside a transaction block. You may need to configure Flyway to run this migration outside of a transaction.

CREATE INDEX CONCURRENTLY order_cancellation_timestamp ON orders USING BTREE(cancellation_timestamp);

-- drop index over (creation_timestamp, cancellation timestamp)
-- since it can only be used optimally for queries on the creation_timestamp.
DROP INDEX CONCURRENTLY IF EXISTS order_creation_cancellation;

[gemini-code-assist]

This index definition appears to be missing DESC for creation_timestamp. The user_orders query typically fetches orders in descending order of creation time, so a descending index is more efficient. The same index is also documented under the order_execution table (line 214) as btree(owner, creation_timestamp DESC), which is likely the correct definition. Please verify and correct this.

Additionally, it seems several indexes are now documented under both orders and order_execution. To avoid confusion, it would be beneficial to clean this up and remove the incorrect entries from the order_execution section in a follow-up.

Suggested change

	- user_order_creation_timestamp: btree(`owner`, `creation_timestamp`)
	- user_order_creation_timestamp: btree(`owner`, `creation_timestamp` DESC)