> 1) disregard the results of the first query timing (this one has to read > the data into the cache)
More correctly, you need to exclude the effects of any operation which primes the cache. This is not necessarily the "first" operation. Far better is to run the queries multiple times in succession (say, 1000) and then average the result. > 2) run each query in a new process (so each one will need to read the data > from disk)> This is untrue. The Operating System caches data between processes. Using a new process will only get rid of in-process cache effects, which are almost non-existant. You are far better to run the test a number of times (say, 1000) and average the results. UInmless of course you are running in a real bitty fondle-slab that has insufficient memory to cache anything at all. > -----Urspr?ngliche Nachricht----- > Von: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] Im Auftrag von ??? > Gesendet: Freitag, 11. Dezember 2015 09:13 > An: SQLite mailing list > Betreff: Re: [sqlite] ABOUT ROWID > > Because of I want to test some funtions of the SQLite. > According to Clemens said, the testing result may be influenced by > cache. > How could avoid the influence of cache? Is there funtion can > eliminate the influence? > > best regards. > WQG > > > > > > > > > At 2015-12-11 15:40:56, "Clemens Ladisch" <clemens at ladisch.de> wrote: > >??? wrote: > >> For example, tableA contains two columns: implicit rowid, A_id. > >> we create index on A_id. > >> firstly, we used rowid to select the row, cost about 400 seconds; > >> secondly, we used A_id to select the row, cost about 200 seconds; > >> thirdly, we also used rowid to select the row, cost about 200 > seconds. > > > >This can be explained by the data being cached. > > > >> if firstly,we used A_id to select the row, cost about 200 seconds; > >> the create index on A_id may have some influence to do with the > rowid. > >> and from this example, I also think the rowid is not implicit index. > > > >If all columns of the table are contained in the index, then the "select > *" > >can read all values from the index itself, without having to look up > >the row in the original table. This is called a covering index. > > > >If your table has more columns, lookups on A_id will become slower. > > > > > >Regards, > >Clemens > >_______________________________________________ > >sqlite-users mailing list > >sqlite-users at mailinglists.sqlite.org > >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > ___________________________________________ > Gunter Hick > Software Engineer > Scientific Games International GmbH > FN 157284 a, HG Wien > Klitschgasse 2-4, A-1130 Vienna, Austria > Tel: +43 1 80100 0 > E-Mail: hick at scigames.at > > This communication (including any attachments) is intended for the use of > the intended recipient(s) only and may contain information that is > confidential, privileged or legally protected. Any unauthorized use or > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please immediately notify the sender > by return e-mail message and delete all copies of the original > communication. Thank you for your cooperation. > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
