Re: [sqlite] SQLite performance with mid-size databases

2004-06-17 Thread ben . carlyle
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

Re: [sqlite] SQLite performance with mid-size databases

2004-06-17 Thread D. Richard Hipp
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.

Re: [sqlite] SQLite performance with mid-size databases

2004-06-17 Thread Raymond Irving
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

Re: [sqlite] SQLite performance with mid-size databases

2004-06-17 Thread Raymond Irving
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

RE: [sqlite] SQLite performance with mid-size databases

2004-06-16 Thread Richard Kuo
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

Re: [sqlite] SQLite performance with mid-size databases

2004-06-16 Thread Derrell . Lipman
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

Re: [sqlite] SQLite performance with mid-size databases

2004-06-16 Thread Jacob Engstrand
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

Re: [sqlite] SQLite performance with mid-size databases

2004-06-16 Thread Nuno Lucas
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

Re: [sqlite] SQLite performance with mid-size databases

2004-06-16 Thread Randall Fox
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

RE: [sqlite] SQLite performance with mid-size databases

2004-06-15 Thread Ionut Filip
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

[sqlite] SQLite performance with mid-size databases

2004-06-15 Thread Richard Kuo
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