Lloyd Thomas wrote:
> There are no indexes in may tables. Please find the following schemas
> for my tables. Would it make more sense to convert my datetime
> columns to microtime?. What other recommendations would you make for
> these tables? CREATE TABLE users (
> user_id INTEGER PRIMARY KEY,
>
I am not a SQLite expert (yet) but I am pretty sure that if you change
this crucial "call_time" field to integer and store data as UNIX date
and create an index on this field you will get a huge speed increase.
Hope it helps,
Tom
Clean Hands
http://www.cleanhands.biz
On Nov 16, 2004, at 5:56 PM,
If I change the call_time to an integer column, storing unix time and make
it hte index, would this help?
- Original Message -
From: "Ulrik Petersen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 16, 2004 11:10 PM
Subject: Re: [sqlite] Speeding up quer
Hi again,
Th
Hi again,
> There are no indexes in may tables. Please find the following schemas for
> my
> tables. Would it make more sense to convert my datetime columns to
> microtime?. What other recommendations would you make for these tables?
> CREATE TABLE users (
> user_id INTEGER PRIMARY KEY,
> extn
There are no indexes in may tables. Please find the following schemas for my
tables. Would it make more sense to convert my datetime columns to
microtime?. What other recommendations would you make for these tables?
CREATE TABLE users (
user_id INTEGER PRIMARY KEY,
extn_no varchar(16) default N
Hi there,
> I am have a problem with a query which may well have over 200,000 records.
> I
> have building a website using PHP and PHP is timing out after 30secs due
> the
> the size of the call_data table (I think). Is there anyway I can improve
> the
> following query so that it is faster. I thi
Lloyd Thomas wrote:
I am have a problem with a query which may well have over 200,000
records. I have building a website using PHP and PHP is timing out
after 30secs due the the size of the call_data table (I think). Is
there anyway I can improve the following query so that it is faster. I
thin
I recently upgraded to SQLite version 3 and have ran into some
performance problems. I had similar problems with 2.8, and solved them
by settting 'PRAGMA default_synchronous=off'.
In SQLite 3, the default_synchronous pragma seems to have been removed.
Is there any way to set this as a default
I am have a problem with a query which may well have over 200,000 records. I
have building a website using PHP and PHP is timing out after 30secs due the
the size of the call_data table (I think). Is there anyway I can improve the
following query so that it is faster. I think I am using sqlite 2
On 14 Nov 2004, at 23:21, Thomas Fjellstrom wrote:
Well technically I think you can add a LIKE operator yourself. I was
going to
get pcre and ad a nice MATCH/REGEX type operator for a program I'm
working
on.
Any chance of releasing that into the wild once it's done? :)
Cheers,
Demitri
Tomas Franzén wrote:
Hi,
I see there's a limit on the amount on data stored per row.
Is there something bad about raising this limit a bit? I.e, is it safe
for me to change this constant to something like... 10 MB?
The file format in version 2.8 imposes a hard limit of 16MB.
There is no harm in r
Hi,
I see there's a limit on the amount on data stored per row.
Is there something bad about raising this limit a bit? I.e, is it safe
for me to change this constant to something like... 10 MB?
Tomas Franzén
Lighthead Software
http://www.lightheadsw.com/
I'm listening to Red Hot Chili Peppers - O
12 matches
Mail list logo
