>
>
> The sqlite3_stmt_status() interface was designed for this purpose.
> http://www.sqlite.org/c3ref/stmt_status.html
>
Thanks for the info, I hope it will be extended also with other counters
I did some test with this Rowid/Id trick. A larger base, 22mb, 100,000
records (220 bytes per record a
On Jan 7, 2010, at 8:18 AM, Tim Romano wrote:
> I don't claim any SQLite expertise, but indexes on values like
> True/False, Male/Female -- i.e. where there are only a couple or a few
> different values possible in the column -- are normally to be
> avoided
> because low-cardinality indexes t
On Jan 29, 2010, at 6:15 AM, Max Vlasov wrote:
> To be sure that there's no
> full or almost-full table scan I use VFS monitoring in such cases.
The sqlite3_stmt_status() interface was designed for this purpose.
http://www.sqlite.org/c3ref/stmt_status.html
D. Richard Hipp
d...@hwaci.com
__
On Fri, Jan 29, 2010 at 6:02 AM, Doyel5 wrote:
> I deleted all indexes, kept only the indexes on the temporary tables,
> namely
> - tempSimArgs and tempPartArgs, and seemingly my original query's running
> time decreased to around 1 sec (when I ran the query the second time). The
> execution time
>The execution time of the first time I run my query varies wildly, I
>dunno why.
Probably due to an empty or dirty cache. That's fairly common with
cache inclined applications, subsystems or OSes. The second time, most
of what's needed is found in cache with much less variability.
Hi Everybody,
Thanks a lot for the suggestions. I really appreciate your help. :-)
Just wanted to share my results..
I deleted all indexes, kept only the indexes on the temporary tables, namely
- tempSimArgs and tempPartArgs, and seemingly my original query's running
time decreased to around 1
-- Original Message -
From: "Igor Tandetnik"
To: sqlite-users@sqlite.org
Sent: Wednesday, January 6, 2010 3:02:23 PM
Subject: Re: [sqlite] SQlite query performs 10 times slower than MS Access
query
Doyel5 wrote:
> I have a 800MB MS Access database that I migrated to SQL
On Thu, Jan 07, 2010 at 08:18:56AM -0500, Tim Romano scratched on the wall:
> I don't claim any SQLite expertise, but indexes on values like
> True/False, Male/Female -- i.e. where there are only a couple or a few
> different values possible in the column -- are normally to be avoided
> becaus
On 7 Jan 2010, at 1:18pm, Tim Romano wrote:
> I don't claim any SQLite expertise, but indexes on values like
> True/False, Male/Female -- i.e. where there are only a couple or a few
> different values possible in the column -- are normally to be avoided
> because low-cardinality indexes tend
I don't claim any SQLite expertise, but indexes on values like
True/False, Male/Female -- i.e. where there are only a couple or a few
different values possible in the column -- are normally to be avoided
because low-cardinality indexes tend to be inefficient. What is the
advice of the SQLite
Doyel5 wrote:
> I have a 800MB MS Access database that I migrated to SQLite. The
> structure of the database is as follows (the SQLite database, after
> migration, is around 330MB):
>
> The table ‘Occurrence’ has 1,600,000 records. The table looks like:
> CREATE TABLE Occurrence
> (
> Simulation
Why you change the query?
Use de Access version or someone without joining a subquery.
Is preferible to join table to table (to more tables) than join table to
subqueries.
Emilio
Doyel5 escribió:
> I have a 800MB MS Access database that I migrated to SQLite. The structure of
> the database is
I have a 800MB MS Access database that I migrated to SQLite. The structure of
the database is as follows (the SQLite database, after migration, is around
330MB):
The table ‘Occurrence’ has 1,600,000 records. The table looks like:
CREATE TABLE Occurrence
(
SimulationID INTEGER,SimRunID IN
13 matches
Mail list logo
