4 ms·

Without indexes, SQLite will do a table scan of sorts, which would still require all pages (=torrent pieces) that have data for a particular table. With indexes

Without indexes, SQLite will do a table scan of sorts, which would still require all pages (=torrent pieces) that have data for a particular table. With indexes however this can be a lot smarter (client likely only needs a few pages from the index for a single query).

tangent128 9y ago
You still need to walk the tree, so you don't know which pages you need immediately- but since the root pages for the indexes should be well-distributed in the swarm, it shouldn't take very long to figure out which leaves you need.
- sktrdie 9y ago
  Yes. I ran real world numbers. Before getting a result you still have to download on average ~20 pieces (32KB * 20 = 640KB). With healthy swarms and a 500kb/s connection you should get results as soon as ~1 second.
  - paxcoder 9y ago
    Is 640KiB not the whole index? Because partial download would mean having to request new pieces based on the previously-downloaded ones, adding latency to the mix. Assuming just 50ms latency, for 20 packets that would account for a whole second before seeing a result. And 20 decisions seems a lot, though I don't know how the index works. What bothers me is that you've rounded the time down in your calculation despite ignoring throughput factors like packet overhead, piece message metadata, other protocol messages and processing time. I'd be interested to see some real time measurements. If you decide to do it (maybe for a research paper?), consider using kibis explicitly (and mind capitalization - b vs B).
sktrdie 9y ago
Indeed. Without indexes it would be quite silly. SQLite supports Full Text Search (and so does TorrentPeek), so results get back after about ~20 pieces are read.