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
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
corr
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, delete
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 - "
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 pr
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 * FROM
> t2) which returns
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 ab
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
http://wanderinghorse.net/home/stephan/
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 SELECTs are used)?
It
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 used)?
It would be. A RO
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
> worry about multi-anythin
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 apart from SQLITE_OK corre
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 ( about 3000 times ).
>
13 matches
Mail list logo