Thanks for all great info so far! >Taking that query out reduces the read() calls back to 99. Do we need >another SQLite index? Can we improve that query?
Your index idea was a good one. I used sqlite3 to back up my wc.db, then ran the query you found, filling in the parameters as appropriate and commenting out the use of IS_STRCT_DESCENDENT() since that is a custom function that I didn't have on hand. Running it with .timer ON I found that the query takes 4.15s to run on average. I then created an index like this: CREATE INDEX bobindex1 ON nodes (kind, presence, op_depth) and now the query consistently takes 0.27s. Really good news! But I wonder if improving the query is a better solution, or at least should ALSO be done. For one thing, it seems that running "svn status" on just a file should implicitly behave as if the --non-recursive flag had been specified, shouldn't it? So I think I'm going to add that index to my actual wc.db to work around the problem myself, but I still think an issue should be created to provide a permanent fix. (And I think the permanent fix would be three things: the index, the implicit --non-recursive behavior for files, and possibly the query optimization if someone can come up with an improvement.) Can I get a "buddy" on this? Thanks again!
