On Sat, Jan 14, 2012 at 11:52 PM, Simon Slavin <slav...@bigfraud.org> wrote:
>
> On 14 Jan 2012, at 7:24pm, Max Vlasov wrote:
>
> > On Sat, Jan 14, 2012 at 6:12 AM, Simon Slavin <slav...@bigfraud.org>
> wrote:
> >
> >> Fast. Fasty fast. Speed is high. INSERT, UPDATE, and DELETE all
> >> significantly faster. SELECT is a bit faster, but there's less
> difference.
> >
> > Simon, very interesting. Can you make some tests related to internal
> >
> > INSERT INTO TestTable (id, text) VALUEs (abs(random() % (1 << 48)),
> > '12345678901234567...') {the text is about 512 bytes long}
>
> If you want to supply the CREATE command and tell me that the '...' in the
> above means that that line should continue to 512 digits, I'm happy to run
> the above. So the speeds are not directly comparable.
>
>
Ok
CREATE TABLE [TestTable] (
[Id] INTEGER PRIMARY KEY AUTOINCREMENT,
[Text] TEXT
)
The string just continues to be 512 bytes in length, I think it can be even
bigger. The idea is for primary key to jump heavily inside the b-tree. As I
understand the test should benefit from infamous almost instant access time
of ssd, but on Asus T91MT having SSD I still noticed degradation toward 50%
of job when the cpu dropped from 80% to 50% (so it's not sqlite who waited)
so either Windows 7 on a 2 years ssd system isn't optimized enough or
something else.
Max
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
