to the older database format:
sqlite334 334.db .dump | sqlite321 321.db
And then perform your timings with both SQLite versions against
the 321.db file to level the playing field.
Just having an index on utime should be optimal for SQLite 3.2.1.
--- Steve Green <[EMAIL PROTECTED]> wrote:
so that optimal performance can be achieved
with all data set sizes?
Thanks for your help,
Steve
Steve Green wrote:
Sorry, I forgot to mention that I'm using sqlite v3.3.4 on redhat linux
v7.3
Steve
Steve Green wrote:
Hi,
I have the following schema
CREATE TABLE data(
utime int4,
r_i
Kurt,
Thanks, the single primary index you suggested does give us the
desired results.
Steve
Kurt Welgehausen wrote:
Steve Green <[EMAIL PROTECTED]> wrote:
CREATE UNIQUE INDEX pk_data on data( utime, r_id, u_id );
...
CREATE INDEX ix_data_ut on data( u_id, utime );
Wouldn't a
u_id >= 0 and utime >= ..., it will cuase the optimal index to be
used (however, if we every started using negative u_id values, it would
break).
What is the best way to send you sample data (and what is the maximum
file size that you'd like)?
Steve
[EMAIL PROTECTED] wrote:
Steve Green &
Sorry, I forgot to mention that I'm using sqlite v3.3.4 on redhat linux
v7.3
Steve
Steve Green wrote:
Hi,
I have the following schema
CREATE TABLE data(
utime int4,
r_id int2,
u_id int4,
data1 int8,
data2 int8
);
Each row is uniquely defined by utime, r_id, and u_id, so
volve rewritting the query, but
I'm at a loss as to how that could be done.
Thanks for your time,
Steve
--
Steve Green
SAVVIS
Transforming Information Technology SM
This message contains information which may be confidential and/or
privileged. Unless you are the intended recipient (or autho
be made in SQLite or the CPAN DBD package?
Thanks,
Christian Werner
--
Steve Green
SAVVIS
Transforming Information Technology SM
This message contains information which may be confidential and/or
privileged. Unless you are the intended recipient (or authorized
to receive for the intended
hat this bug may be corrected when CROSS JOIN is not used.
--- Steve Green <[EMAIL PROTECTED]> wrote:
Interestingly, using
from t1
cross join t2
fixes the problem; using this, causes indices from both tables to be used...
addr opcode p1
is a bug in the join optimizer.
Try using an explicit CROSS JOIN.
select t1.a, t1.b, t2.c, t2.d
from t1
cross join t2
where t1.x = t2.x and t1.a >= 100 and t1.a < 200
group by t1.a, t1.b, t2.c, t2.d
--- Steve Green <[EMAIL PROTECTED]> wrote:
The performance is exactl
is missing.
This would cover 99% of the pre-SQLite3.2.3 legacy databases
out there where the queries have already been hand-tuned.
--- Steve Green <[EMAIL PROTECTED]> wrote:
Hi,
I currently have a v3.2.0 database that contains two tables that I regularly
query with a join, e.g.,
selectt1.a
we can improve the performance using v3.3.x (we'd really like
to
use the most current version of the database, but the performance difference
would
be a killer)?
Thanks,
Steve
--
Steve Green
SAVVIS
Transforming Information Technology SM
This message contains information which may be confid
Thanks, that seems to have fixed the problem...
Steve
Eric Bohlman wrote:
Nathan Kurz wrote:
On Mon, Mar 06, 2006 at 06:24:13PM -0800, Steve Green wrote:
Hi,
I'm hoping that someone can shed some light on the following issue that
I'm seeing. When I attempt to create a temp table using
sconnect();
exit 0;
When this code is run using SQLite v3.3.2 (or apparently any older version; we
also tried 3.3.1, 3.3.0, 3.2.7 and 3.2.0), there is no error. No modifications
to any of the installations were made.
We are using perl 5.6.1 on Linux 2.6.12.6-nfs #1 SMP.
Thanks for any help you can prov
13 matches
Mail list logo
