To: [EMAIL PROTECTED]
cc:
Subject: Re: [sqlite] SQLite performance with mid-size databases
Well this does not sound good at all. I would think
that SQLite would at least do a better job at queries.
The issues with performance and scalability is of
great concern. I was plann
Ulrik Petersen wrote:
this is also just a stab in the dark, and I subscribe to the digest
version of the mailinglist, so I may not have the latest.
Perhaps you are doing something like
SELECT A.x, A.y
FROM A
WHERE A.rowid = xxx
OR A.rowid = yyy
OR A.rowid = zzz
OR A.rowid = ...
etc.etc.
See below:
--- Jacob Engstrand <[EMAIL PROTECTED]> wrote:
> To disable the
> I1A index,
> rewrite the WHERE clause like this:
>
> SELECT * FROM t1 WHERE a+0=5 AND b='xyzzy';
>
> To disable the I1B index you could write
>
> SELECT * FROM t1 WHERE a=5 AND b LIKE 'xyzzy';
>
Why
Well this does not sound good at all. I would think
that SQLite would at least do a better job at queries.
The issues with performance and scalability is of
great concern. I was planning on create some new apps
that use SQLite, but now I'm wondering is this little
database is capable of handle
is very favorably impacting the speed of the queries.
Richard
-Original Message-
From: Tim Anderson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 16, 2004 10:33 AM
To: Richard Kuo
Subject: RE: [sqlite] SQLite performance with mid-size databases
> -Original Message-
> From: R
On 2003-01-27, at 00.00, D. Richard Hipp wrote:
> Enterprise scale database engines do a more sophisticated job
> of selecting indices (when there is a choice like this) by
> collecting lots of statistics on the indices and using complex
> algorithms to make the choice. SQLite takes the easy way
On 2004-06-16, at 06.04, Richard Kuo wrote:
Empirically speaking, we display our data in a scrolling 2
dimensional grid format. With MS access, this grid responds
instantaneously when moving through the grid. With SQLite, there is
very noticable stalling and lag and the disk i/o is higher
This could be related with the grid handling code.
In another post I already talked about the "SELECT COUNT(*) ..." performance problem,
that can only be solved by tuning the code in the grid control itself.
If the code is generic, it's a strong possibility it isn't optimized for this, and
On Tue, 15 Jun 2004 23:04:04 -0500, you wrote:
>Hi. We are using SQLite to store and retrieve data rows where each
>row is roughly 2K total in size and in a table of 15 columns. The total
>size of the database ranges from 100-300 MB.
>
>The problem we are seeing is that query and
AIL PROTECTED]
Sent: Wednesday, June 16, 2004 7:04 AM
To: [EMAIL PROTECTED]
Subject: [sqlite] SQLite performance with mid-size databases
Hi. We are using SQLite to store and retrieve data rows where each
row is roughly 2K total in size and in a table of 15 columns. The total
size of the datab
Hi. We are using SQLite to store and retrieve data rows where each
row is roughly 2K total in size and in a table of 15 columns. The total
size of the database ranges from 100-300 MB.
The problem we are seeing is that query and insert performance is
unusually bad and scales up linearly
11 matches
Mail list logo