Joe,
Thanks for the info...
Unfortunately, we don't have the option of moving back to v3.2.1. However,
I'm curious as well to see the difference in performance, so when (if?) I
get my current performance issues under control, I'll run the test and
post the results.
Steve
Joe Wilson wrote:
If
If you test against 3.2.1, just use your original where clause
and original index pk_data:
where utime >= 1146441600 and utime < 114912
as I don't know what effect the unary +'s would have on it.
--- Joe Wilson <[EMAIL PROTECTED]> wrote:
> For my databases, GROUP BY is slower in recent SQL
For my databases, GROUP BY is slower in recent SQLite releases
because my queries are not able to use indexed columns for
GROUP BY items by design:
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg15563.html
I'm curious what sort of timings you'd get with SQLite 3.2.1.
http://sqlite.org
Using Richard's suggestion of changing the where clause of my query
to
where +utime >= 1146441600 and +utime < 114912000
did force sqlite to use the index that gave better performance.
However, I'm seeing some strange behavior that I'm hoping someone can
shed some light on.
With the time perio
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
5 matches
Mail list logo
