Le ven 18/06/2004 à 03:23, [EMAIL PROTECTED] a écrit :
> I'm using sqlite in heavily-loaded system consisting of database files
> that are created over a two-day period. The average database file is about
> 800 meg. After extensive testing early in the piece I concluded that only
> sqlite was su
--Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 3:15 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [sqlite] RE: SQLite performance with mid-size databases
Richard,
I notice you don't seem to be getting us
"Ismail Kizir" <[EMAIL PROTECTED]>
17/06/2004 06:48 PM
To: <[EMAIL PROTECTED]>
cc:
Subject: Re: [sqlite] RE: SQLite performance with mid-size databases
> I had the same problem as Richard's.
> Unfortunately, i have decided
Jacob Engstrand wrote:
>
> On 2004-06-17, at 16.39, [EMAIL PROTECTED] wrote:
>
>> If you have a large record size, then it also helps tremendously to put the
>> indexed columns first in the row (I had a table with large blob data that
>> was terribly slow to query until I moved the small, non-blob
On 2004-06-17, at 16.39, [EMAIL PROTECTED] wrote:
If you have a large record size, then it also helps tremendously to
put the
indexed columns first in the row (I had a table with large blob data
that
was terribly slow to query until I moved the small, non-blob columns
first).
[That was found out
Another performance issue to consider are the queries you are submitting. I
saw one person mention using a LIKE or GLOB. Use of these operators
(without another criteria first that will utilize an index) will ALWAYS
result in a table scan. Actually, anytime a function is used in the WHERE
clause
Richard,
I notice you don't seem to be getting useful replies on this list, and I
think perhaps that it is in part a lack of useful input on your part that
is holding up the works. Here is my suggestion:
1) Take a copy of your working database
2) Try the exact sql query you believe to be scaling
7 matches
Mail list logo
