Re: [sqlite] Strange performance problem

I've tried that before but now I've found out I had empty "begin" implementation in my wrapper, now it works, thank you. On Mon, Sep 5, 2011 at 6:59 PM, Dan Kennedy wrote: > On 09/05/2011 10:47 PM, Rado Rado wrote: > >> I'm running simple prepared SELECT statement in loop

Re: [sqlite] Strange performance problem

On 5 Sep 2011, at 6:24pm, Stephan Beal wrote: > On Mon, Sep 5, 2011 at 7:11 PM, Simon Slavin wrote: > >> It should be. However, if you have a multi-user, multi-process or >> multi-thread setup, please make absolutely certain that you handle all >> SQLite result codes

Re: [sqlite] Strange performance problem

On Mon, Sep 5, 2011 at 7:11 PM, Simon Slavin wrote: > It should be. However, if you have a multi-user, multi-process or > multi-thread setup, please make absolutely certain that you handle all > SQLite result codes apart from SQLITE_OK correctly. If you don't have to >

Re: [sqlite] Strange performance problem

On 09/06/2011 12:04 AM, Stephan Beal wrote: On Mon, Sep 5, 2011 at 6:59 PM, Dan Kennedy wrote: You could get the same effect by wrapping your loop in a BEGIN/COMMIT block. Out of curiosity: would a BEGIN/ROLLBACK be equivalent for this case (where only SELECTs are

Re: [sqlite] Strange performance problem

On 5 Sep 2011, at 6:04pm, Stephan Beal wrote: > On Mon, Sep 5, 2011 at 6:59 PM, Dan Kennedy wrote: > >> You could get the same effect by wrapping your loop in a BEGIN/COMMIT >> block. > > Out of curiosity: would a BEGIN/ROLLBACK be equivalent for this case (where > only

Re: [sqlite] Strange performance problem

On Mon, Sep 5, 2011 at 6:59 PM, Dan Kennedy wrote: > You could get the same effect by wrapping your loop in a BEGIN/COMMIT > block. Out of curiosity: would a BEGIN/ROLLBACK be equivalent for this case (where only SELECTs are used)? -- - stephan beal

Re: [sqlite] Strange performance problem

On 09/05/2011 10:47 PM, Rado Rado wrote: I'm running simple prepared SELECT statement in loop ( about 3000 times ). It is something like "SELECT value FROM t WHERE t_id=? AND name=?". For most calls the row does not exist, step() returns SQLITE_DONE so I call reset after that(). The loop takes

Re: [sqlite] Strange performance problem

On Mon, Sep 5, 2011 at 5:47 PM, Rado Rado wrote: > I'm running simple prepared SELECT statement in loop ( about 3000 times ). > It is something like "SELECT value FROM t WHERE t_id=? AND name=?". ,,, > When I execute any SELECT query (using different table, like SELECT *

[sqlite] Strange performance problem

I'm running simple prepared SELECT statement in loop ( about 3000 times ). It is something like "SELECT value FROM t WHERE t_id=? AND name=?". For most calls the row does not exist, step() returns SQLITE_DONE so I call reset after that(). The loop takes about 0.25 second and result seems to be

Re: [sqlite] Strange performance problem

Hi Michael I tried your example and have experienced the same results. Then I created the following two indices, now the two queries are same fast: CN_execute "CREATE INDEX idx_t1_id ON t1 (id)" CN_execute "CREATE INDEX idx_t2_id ON t2 (id)" It seems that sqlite doesn't create an index for

Re: [sqlite] Strange performance problem

Khamis Abuelkomboz wrote: CREATE INDEX idx_t2_t1id ON t2 (t1id, deleted); Doent not help. whereas the following quere takes "no" time: SELECT COUNT(*) FROM t2 LEFT JOIN t1 ON t1.id=t2.id WHERE t1.deleted<>1 This is fast, because no entries has been found to be joined. This is not true -

Re: [sqlite] Strange performance problem

Michael Gross wrote: Hello I use sqlite 3.2.2. I have a strange performance problem. I am able to solve the problem by a slight change in the query but I want to ask if somebody can explain this behavior to me: I have two tables: CREATE TABLE t1 (id VARCHAR(40) NOT NULL PRIMARY KEY,

[sqlite] Strange performance problem

Hello I use sqlite 3.2.2. I have a strange performance problem. I am able to solve the problem by a slight change in the query but I want to ask if somebody can explain this behavior to me: I have two tables: CREATE TABLE t1 (id VARCHAR(40) NOT NULL PRIMARY KEY, deleted BIT); CREATE TABLE