Contributors to this thread:

i added code to log slow queries in ktistec and it's already paying dividends. most are obviously missing indexes and it's great to fix them, but the latest example—which is missing an index—is querying a table that only has one row (in my single user instance). should that table need an index on that column? i mean, just return that row...

fwiw, a slow query is currently anything that takes longer than 50msec. i wonder if that is tight enough...?


@toddsundsted I don't fully get it but yes, there doesn't seem to be a good reason for a table with a single row take that long to be scanned and to return a value. The only thing that I am reminded of was when we were using SQLite3 and things were slow because our "simplified" API wrapper mistakenly was reopening the database, running the query, and then returning the data and closing it again for every query!

@onghu thanks! yes, i haven't ruled out bugs somewhere else. running the query in the console does confirm it is scanning the table. on the other hand, the timing indicates a reasonable 6msec—not the 100+msec i'm seeing in the application...

@toddsundsted yeah, if you go deep enough in this rabbit hole, it might be beneficial to have index for even a tiny amount of records, because query planner can use index to find record in just one tree check hop and just fetch it by it’s internal address.

Otherwise it uses diffirent search algo for “table scan” & it’s usually slower. Weird but works, especially if you have very hot small table.

Not sure though what qps you need so see effect on 1-record-table. But on 100’s it’s visible.

@alex yeah, i'm going to give it a try. it's one account per user, and i only support one user now, but that could change. i also can't imagine that the cost of that index is going to be a problem.

@toddsundsted @alexanderadam also try to find tool for your DB that can watch frequency of query shapes. 1000s of 0.05ms queries (like bogus 1-many loads) might have tremendous effect on performance and they won’t be visible in slow query logs