bt90

Maybe we can apply some sharding here? The same technique helped us scaling at the folder level. But I fear it's going to be a lot harder as we ultimately...

The blocklists table is the main offender judging from real world stats: https://forum.syncthing.net/t/database-or-disk-is-full-might-be-syncthing-might-be-qnap/24930/7 That's ~85% of the whole DB layer

So it's rather a thing influenced by row count and in turn index updates? Maybe we can partition the blocks table as a startpoint.

We could try to avoid a lot of index shuffling if we insert the blocks in order aka sorting them according to the PK prior to inserting them.

> There is no relevant sort order when it's indexed on hash which is essentially random and we're inserting random records in a table with many millions of rows already....

I've noticed that we don't really tell the browser how the deal with the input regarding autocomplete. Maybe https://github.com/syncthing/syncthing/pull/10342 might solve this?

I don't understand the hate for `io_uring`. Google is mostly having problems with older LTS kernels and many people are judging based on inflated CVE numbers. The kernel developers fixed...

We're targeting ARMv6 since syncthing v2: https://github.com/syncthing/syncthing/commit/1b8a8032f0ae9f5350c89c8ac3eea7bff887ac46 But I think you should still be able to compile it yourself