Yup...I'm sure...
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 Peter Aronson [pbaron...@att.net] Sent: Sunday, January 15, 2012 4:18 PM To: 'General Discussion of SQLite Database' Subject: EXT :Re: [sqlite] SSD with TRIM You know, on some platforms, such as Solaris, /tmp can be configured to use memory instead of disk (called tmpfs on many unix variants). Are you sure your /tmp is actually using disk? It's the default in a lot of setups. Best Peter > -----Original Message----- > From: sqlite-users-boun...@sqlite.org [<thismessage:/>mailto:sqlite-users- > boun...@sqlite.org] On Behalf Of Black, Michael (IS) > Sent: Sunday, January 15, 2012 12:35 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] SSD with TRIM > > 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 _______________________________________________ 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
