=== On 2004-06-18, ben.carlyle wrote ===
..
>
>I'd like to take this soapbox opportunity to again thank drh and his
>associates for the wonderful work they put into sqlite and their genine
>personal commitment to this project. Sqlite is a great product, and a
>well-targeted one.
>
>Benjamin
>
J
TED]>
18/06/2004 12:09 AM
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 scal
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. with
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 ov
f data is visibly faster...indicating that
>the disk cache 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
>Subje
Richard Kuo wrote:
I suspect some unnecessary disk access has to be the problem...despite
the small amount of new guide information being queried out, disk bytes
read is several times higher than with MS access and scrolling back over
previously accessed areas of data is visibly faster...indicating
he 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-
> Fr
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 tha
> -Original Message-
> From: Richard Kuo [mailto:[EMAIL PROTECTED]
> Sent: 16 June 2004 05:04
> 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 siz
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
assume
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 insert
> 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 than MS
> Access by roughly
Hi Richard,
Here is a tip to speed up the insert operations: use prepared statements
instead of plain INSERTs. If you have to insert more than one record with
the same format the performance increase is significant.
Transactions also speeds up db operations, there are more detailed topics
about t
15 matches
Mail list logo
