improve search performance by scanning with the timestamp index iteratively

Or else SQLite uses the command index and sort. Even with the timestamp
index, SQLite still needs sort.

This is what atuin uses:

select * from history indexed by idx_history_command where deleted_at is null group by command having max(timestamp) order by timestamp desc limit 100;
|--SCAN history USING INDEX idx_history_command
`--USE TEMP B-TREE FOR ORDER BY

Try to tell SQLite to use the timestamp index. Slightly faster.

select * from history indexed by idx_history_timestamp where deleted_at is null group by command having max(timestamp) order by timestamp desc limit 100;
|--SCAN history USING INDEX idx_history_timestamp
|--USE TEMP B-TREE FOR GROUP BY
`--USE TEMP B-TREE FOR ORDER BY

The fastest index to use is...not to use an index at all.

select * from history not indexed where deleted_at is null group by command having max(timestamp) order by timestamp desc limit 100;
QUERY PLAN
|--SCAN history
|--USE TEMP B-TREE FOR GROUP BY
`--USE TEMP B-TREE FOR ORDER BY

The last one is very fast, but it might not fetch enough rows due to
duplications. So we do the deduplication ourselves instead and let
SQLite just scan using the index and never sort.

select * from (select * from history where deleted_at is null order by timestamp desc limit 1000) group by command having max(timestamp);
QUERY PLAN
|--CO-ROUTINE (subquery-1)
|  `--SCAN history USING INDEX idx_history_timestamp
|--SCAN (subquery-1)
`--USE TEMP B-TREE FOR GROUP BY

For the following command, the elpased times are (lowest among several runs):

atuin search --search-mode fuzzy --limit 100 --cmd-only > /dev/null

command index   : 0.154s
timestamp index : 0.139s
no index        : 0.124s
paging          : 0.012s

Author: lilydjwg