> > The logic is, "keep a given (k1, k2) pair around for one day for each > > time it's been seen". I could calculate it when it's needed, but > > since it's a computed value, I couldn't then have an index on it. > > I'm not sure about SQLite, but in principle the query optimizer can > often use the base table's index for a derived value. Consider > > A join B on A.a = 1 + B.a > or > A join B on A.a < sqrt(B.a) > > An index on B.a is useful to finding the values meeting the criterion. > > But perhaps you've measured this. How much faster is the updating > process you're concerned with than the SELECT that would avoid it?
I've measured the performance gain of leaving off that column (and therefore index) entirely. It buys me less than my rounding error in performance for the updates. I only left it in the problem description for completeness. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
