Re: [sqlite] Full Table Scan after Analyze

On 25 Mar 2011, at 11:11pm, Jay A. Kreibich wrote: > On Fri, Mar 25, 2011 at 10:30:59PM +, Simon Slavin scratched on the wall: > >> Actually I'm surprised and not terribly impressed that SQLite ever >> does a scan when there's an ideal index available. > > Why? Do you want it to run

Re: [sqlite] Full Table Scan after Analyze

On Fri, Mar 25, 2011 at 10:30:59PM +, Simon Slavin scratched on the wall: > Actually I'm surprised and not terribly impressed that SQLite ever > does a scan when there's an ideal index available. Why? Do you want it to run slower? Indexes are not magic bullets. Using an index to

Re: [sqlite] Full Table Scan after Analyze

> Suggestion: After you run ANALYZE, go back and modify values in > sqlite_stat1 (and sqlite_stat2 if you are using SQLITE_ENABLE_STAT2) with > "typical" values that you would expect to see in most databases. Yes, you > can read and write the sqlite_stat1 and sqlite_stat2 tables. Maybe you can

Re: [sqlite] Full Table Scan after Analyze

On Fri, Mar 25, 2011 at 6:30 PM, Simon Slavin wrote: > > On 25 Mar 2011, at 10:18pm, Richard Hipp wrote: > > > Suggestion: After you run ANALYZE, go back and modify values in > > sqlite_stat1 (and sqlite_stat2 if you are using SQLITE_ENABLE_STAT2) with > > "typical" values

Re: [sqlite] Full Table Scan after Analyze

On 25 Mar 2011, at 10:18pm, Richard Hipp wrote: > Suggestion: After you run ANALYZE, go back and modify values in > sqlite_stat1 (and sqlite_stat2 if you are using SQLITE_ENABLE_STAT2) with > "typical" values that you would expect to see in most databases. Yes, you > can read and write the

Re: [sqlite] Full Table Scan after Analyze

On Fri, Mar 25, 2011 at 5:24 PM, Eric Minbiole wrote: > We have an application that has been using SQLite successfully for several > years. We use SQLite for various purposes within our product, with a few > dozen tables overall. > > Recently, I started to upgrade from

[sqlite] Full Table Scan after Analyze

We have an application that has been using SQLite successfully for several years. We use SQLite for various purposes within our product, with a few dozen tables overall. Recently, I started to upgrade from version 3.6.3 to 3.7.5. During that time, I noticed that several previously fast indexed

Re: [sqlite] Capitalisation

J Trahair wrote: > Hi. I've noticed that SELECT statements are specific to the capitalisation of > the WHERE section. > > Suppose I have a Customers table with a CustomerCode field, and a value in > one of the records of TRA001, eg: > > CustomerCode

Re: [sqlite] Capitalisation

On Fri, 25 Mar 2011 10:35:37 +0100 "J Trahair" wrote: > If the SELECT statement is SELECT * FROM Customers WHERE CustomerCode = > 'tra001' that is, with tra001 in lower case, SQLite *does not find the > record*. SELECT * FROM Customers WHERE CustomerCode LIKE

Re: [sqlite] Capitalisation

J Trahair writes: [...] > SELECT * FROM Customers WHERE CustomerCode = 'tra001' > that is, with tra001 in > lower case, SQLite *does not find the record*. [...] use LIKE (http://www.sqlite.org/lang_expr.html#like) SELECT * FROM Customers WHERE CustomerCode LIKE 'tra001'

Re: [sqlite] Capitalisation

On Fri, Mar 25, 2011 at 2:35 AM, J Trahair wrote: > Hi. I've noticed that SELECT statements are specific to the capitalisation of > the WHERE section. > > Suppose I have a Customers table with a CustomerCode field, and a value in > one of the records of TRA001,

[sqlite] Capitalisation

Hi. I've noticed that SELECT statements are specific to the capitalisation of the WHERE section. Suppose I have a Customers table with a CustomerCode field, and a value in one of the records of TRA001, eg: CustomerCode CustomerName TRA001 Trahair SMI001 Smith If the