Re: [sqlite] bad index selection?

On Mon, Mar 9, 2009 at 12:08 AM, Igor Tandetnik wrote: > > It can't. "hash" column is not part of the index. > Right... I should have seen that. > > Would re-ordering our unique index to be (name, id, value, ...) > > rather than (name, value, id, ...) allow a query with

Re: [sqlite] bad index selection?

"Derek Scherger" wrote in message news:e97446630903082113x1efb0173mfde6aa70909b1...@mail.gmail.com > I'm curious though, why does 'select *' not also use the unique index > on the > same grounds that it could get all the values it needs from the index > and > avoid the table

Re: [sqlite] bad index selection?

On Sun, Mar 8, 2009 at 9:46 PM, Igor Tandetnik wrote: > When all columns in the SELECT come from the index, SQLite can get all > their values directly from the index and avoid reading actual table. So > it saves an index-to-table lookup. > Thanks, that helps. > Note also

Re: [sqlite] bad index selection?

"Derek Scherger" wrote in message news:e97446630903081908l51d3303x507f72865fde1...@mail.gmail.com > It seems like sqlite (3.6.6.2) chooses different indexes depending on > which columns are selected for *output* and I wonder whether this is > a bug? > > -- 1. selecting