To answer Richard - it's orders of magnitude faster with the index than table scan + recompute across the table (milliseconds vs. minutes). Keith - in the real example, x is a 1kb blob field, and length(x) is a compute-intensive operation over that blob. This makes the index rows MUCH smaller than the table rows (200 per page instead of 4 per page), so it ends up being a lot faster. However, I never manage to get the indexed picked up automatically on actual database queries without forcing it in. This is actually the main issue - the first part was a red herring - sorry. I figured since it repros for the small field as well I thought it was just a systemic issue rather than a miss based on analysis. Note that if I throw a `WHERE` into the query it DOES indeed pick the index. E.g. This picks the index: ``` SELECT length(x) FROM test WHERE length(x) > 50; ``` But in this case I don't want to filter the query, I just want to use the index for the purpose of picking up the covering pre-computed result of the expression column, which I can't seem to get to work without forcing. If you could confirm that the optimizer is supposed to at least sometimes be capable of automatically picking the index in such a case (no `where` clause, but with covering expression columns), I'll try and isolate my repro further.