Mark Gilbert wrote:
>
> In fact we stumbled across the solution, and I am amazed we didnt
> think of it earlier, and no-one suggested it. Basically our LEAVES
> table doesn't have an Index !!
>
> As soon as we added an index, the process sped up by 17000% :-)
>
> However, I have some questi
shouldn't leafID be the primary key of your LEAVES table and thus already
indexed? What does your create table statement look like? I'd expect
CREATE TABLE Leaves (LeafID INTEGER PRIMARY KEY AUTOINCREMENT, ... other
columns ... )
As far as the create index failing, no idea there, sorry..
Sam
, 28 Feb 2008 21:25:35 -0500
>From: "Samuel Neff" <[EMAIL PROTECTED]>
>Subject: Re: [sqlite] Optimization Question for SQLite Experts
>To: "General Discussion of SQLite Database"
>
>Here's two suggestions. First the simple suggestion is instead of th
You obviously have a set of UID's at the time of the loop, how about
creating a huge select .. from where ...IN (list_of_uids_comma_separated)?
It'll be one single query (or you can break it down into blocks of 50,
or 100, etc).
Will save the overhead of generating the queries over and over again
Here's two suggestions. First the simple suggestion is instead of this..
for (z=0;z wrote:
> Folks.
>
> Looking for some advice from hardened SQliters...
>
> ...
For each twig we have to find all the leaves. The Leaves table has
> maybe 15000 records and we have a query where we search the Le
Folks.
Looking for some advice from hardened SQliters...
- Our application uses an SQLite 3.4.1 database with 8 tables. 1 of
the tables may contain tens or maybe hundreds of thousands of records
with about 30 fields.
- The tables form a linked tree type hierarchy where one table is the
trunk
6 matches
Mail list logo
