[t-bast]

We were previously using a composite index on both the channel_id and the commitment_number in the htlc_infos table. This table is used to store historical HTLC information to be able to publish penalty txs when a malicious peer publishes a revoked commitment. This table is usually the largest DB table on nodes that relay a lot of payments, because it grows with the number of HTLCs received and sent (and only shrinks when channels are closed or spliced).

Using a composite index makes sense, but leads to increased memory usage compared to separate indices, thus reducing performance because this is a table on which we write a lot, but almost never read (only when we detect a revoked force-close). The read performance doesn't seem to be negatively impacted anyway when splitting the indices, and the memory usage is greatly improved.

The migration may take some time depending on the size of the table, but we cannot get around this.

Thanks to @DerEwige for the performance investigation that lead to this change (see #2932 for more details).

[t-bast]

Note that I didn't add any test because we already have migration tests from v2 to the latest version that fill the htlc_infos table and verify that we can still read its contents after the migration, so we shouldn't need any new test.

[t-bast]

I've ran some tests on a local snapshot of our node's DB. I'm running postgres directly on my dev laptop and triggering the migration from that same machine, so results will likely differ from a real deployment, but they're still instructive:

• the migration took ~30 seconds
• the previous index was 1.6Gb while the new indices are only 170Mb
• performance of queries on the DB didn't change

[pm47]

LGTM, sorry for the late review!