Hubertus wrote:
Well now, if this isn't something!
fist I wann thank you for your quick reply. Finally I have to wait for my result
satisfying 0.6 sec. This is great. Now I can add lots more data.
What I did:
- I added a second index for the column "campId" and did the analyze trick
(I had
Hubertus wrote:
Dear John,
You might also look at using the Sqlite date format rather than seperate
columns for year, month etc.
That was what I considered first. The problem was, that other people
are also supposed to use this datbase. Some of them use Fortran and they
said that it's easier
Did you ever determine the cardinality of the campID field? I'm guessing its
pretty good since your query is now .6 seconds.
Lets say your cardinality was low, ie say less than .3 (arbitrary number).
Then using the index to perform you data lookups would probably be slower than
just reading
Dear John,
> You might also look at using the Sqlite date format rather than seperate
> columns for year, month etc.
That was what I considered first. The problem was, that other people
are also supposed to use this datbase. Some of them use Fortran and they
said that it's easier to compile the
Well now, if this isn't something!
fist I wann thank you for your quick reply. Finally I have to wait for my result
satisfying 0.6 sec. This is great. Now I can add lots more data.
What I did:
- I added a second index for the column "campId" and did the analyze trick
(I had this column in the
On 3/19/07, Hubertus <[EMAIL PROTECTED]> wrote:
Dear list,
sorry to just come up with another performance question. I build a yet small
database with one table. It has about 650.000 rows, 75 columns and
has at the moment about 650 Mb. It runs on a Intel Pentium M with 2 GHz. The
Laptop runs Suse
First, you have your double and single quotes mixed up. SQL uses single
quotes for literals.
Second, you are performing row scans and not using any of your indices.
You will do better if you have an index on the column you specify in
your search.
You might also look at using the Sqlite
Hubertus wrote:
This is the schema:
CREATE TABLE 'data'('nr' INTEGER PRIMARY KEY,
'year' INTEGER,
'month' INTEGER,
'day' INTEGER,
'sec' REAL,
'campId' TEXT,
'flightNr' INTEGER,
'1' REAL,
...
'71' REAL
);
You should use double quotes around column and table names. Single
Hubertus uttered:
Dear list,
sorry to just come up with another performance question. I build a yet small
database with one table. It has about 650.000 rows, 75 columns and
has at the moment about 650 Mb. It runs on a Intel Pentium M with 2 GHz. The
Laptop runs Suse 10.2 and does basicly
Looks like it is going to do a full scan of the entire database to complete
that querry based upon your where clause.
Are you always accessing the data by campID? What is the cardinality of
campId data?
Depending upon that it might be worth while putting and index on CampID.
Hubertus
Dear list,
sorry to just come up with another performance question. I build a yet small
database with one table. It has about 650.000 rows, 75 columns and
has at the moment about 650 Mb. It runs on a Intel Pentium M with 2 GHz. The
Laptop runs Suse 10.2 and does basicly nothing but this
11 matches
Mail list logo
