Jim Wilcoxson wrote:
> Insert times should be constant for the 2nd case: no primary key, no
> indexes; ie, it doesn't matter how many records are already in the
> database. I confirmed this with SQLite 3.6.18.
Definitely not constant. Looks linear to me -- you saw the plot, you
can decide for yourself.
I'm in SQLite 3.6.23.1. How do I score an old version to test it?
> Did you see my earlier note about combining your two integers into the
> primary key? This will also give you constant insert times, if you
> insert items in the order:
Hey sorry, I didn't see that. Cute idea, but my accessors are in Tcl,
I don't want to do bit twiddling or query mangling on the read side from
Tcl, and I don't want to re-write it in C. Plus a host of other reasons
that would bore the SQLite community. I'm actually rather happy without
any primary key definition right now.
Thanks also for the tip on insertion order. Does that also hold for
multi-column indices (and not single-column indices transformed from two
integers)? I assume it's because we get more cache hits and fewer tree
rebalances when we insert in key-order?
Before I make any more adjustments, I want to understand why I'm linear
with no indices!
I'm pretty sure I'm not doing anything stupid, like setting evil
compile-time options or whatever. But then again most stupid people
don't think their results come from being stupid.
Eric
--
Eric A. Smith
Aeropalmics (ayr o palm' iks), n.:
The study of wind resistance conducted by holding a cupped
hand out the car window.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
