Hi, Just following up - is this tracked somewhere in a feature/bug database?
I have to do some interesting gymnastics to work around this all the time, since the query optimizer seems to think it can read covered values from an expression index, but during execution it doesn't. e.g. On the example below, a query like: SELECT func(col), count(*) FROM FOO GROUP BY func(col) Will try to use FOOINDEX, but that's a really bad index since it then proceeds to executes func(col) on every row from the index, but FOOINDEX doesn't actually contain col, only the result - func(col). - Deon -----Original Message----- > On 8/31/16, Deon Brewis <[email protected]> wrote: > > Let's say I have an expression index: > CREATE INDEX FOOINDEX on FOO(func(col)) > > And then I use that index: > SELECT bar FROM FOO INDEXED BY FOOINDEX WHERE func(col) = 42; > > I can see that it will use the stored value, since if I put a breakpoint on > func, it won't hit. Good and well. >> > HOWEVER, if I run: > SELECT func(col) FROM FOO INDEXED BY FOOINDEX WHERE func(col) = 42 > > It will execute the breakpoint on func(col) for every row in the > table, even though FOOINDEX is a covered index wrt. that query. > > Is there a way to avoid this? I would just like to return the value that's > already stored in the index. We will take this as an enhancement request. -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
