I ran your test on my SSD system with 1M inserts. I used WAL mode.
pragma journal_mode=WAL;
CREATE TABLE [TestTable] (
[Id] INTEGER PRIMARY KEY AUTOINCREMENT,
[Text] TEXT
);
begin;
insert.....
end;
On SSD:
time sqlite3 gen.db <gen.sql
wal
real 3m35.462s
user 2m14.126s
sys 1m10.718s
On same machine but on /tmp
time sqlite3 gen.db </mnt/ssd/gen.sql
wal
real 3m44.259s
user 2m15.960s
sys 1m9.437s
Or did you have some other test in mind?
Michael D. Black
Senior Scientist
Advanced Analytics Directorate
Advanced GEOINT Solutions Operating Unit
Northrop Grumman Information Systems
________________________________
From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on
behalf of Max Vlasov [max.vla...@gmail.com]
Sent: Saturday, January 14, 2012 1:24 PM
To: General Discussion of SQLite Database
Subject: EXT :Re: [sqlite] SSD with TRIM
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
fragmentation? As an advanced user of sqlite, you probably will easily
invent your own tests :), but if not there is a test I used at least once
INSERT INTO TestTable (id, text) VALUEs (abs(random() % (1 << 48)),
'12345678901234567...') {the text is about 512 bytes long}
1,000,000 inserts should create a 1GB base and the time with general hd was
above 15 minutes, maybe even half an hour. So I'm very interested to see
was there any progress with overall ssd performance.
Thanks,
Max
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
