[sqlite] Is rowid the fastest?
When it revert back after dropping the index. The speed does not become slower. At 2015-12-14 21:35:03, "Hick Gunter" wrote: >Does it revert back to slower speed after dropping the index? >Can you compare the EXPLAIN output produced with and without the index? > >There is no difference on my machine (Version 3.7.14); if yours behaves the >same way then whatever changes speed is definitely not because SQLite is doing >something differently. > >asql> create temp table t (x integer primary key asc, y,z); >asql> .explain >asql> explain select * from t where rowid=15; >addr opcode p1p2p3p4 p5 comment > - - -- - >0 Trace 0 0 000 NULL >1 Integer151 000 NULL >2 Goto 0 12000 NULL >3 OpenRead 0 2 1 3 00 t >4 MustBeInt 1 10000 NULL >5 NotExists 0 10100 pk >6 Rowid 0 3 000 NULL >7 Column 0 1 400 t.y >8 Column 0 2 500 t.z >9 ResultRow 3 3 000 NULL >10Close 0 0 000 NULL >11Halt 0 0 000 NULL >12Transaction1 0 000 NULL >13VerifyCookie 1 1 000 NULL >14TableLock 1 2 0 t 00 NULL >15Goto 0 3 000 NULL >asql> explain select * from t where x=15; >addr opcode p1p2p3p4 p5 comment > - - -- - >0 Trace 0 0 000 NULL >1 Integer151 000 NULL >2 Goto 0 12000 NULL >3 OpenRead 0 2 1 3 00 t >4 MustBeInt 1 10000 NULL >5 NotExists 0 10100 pk >6 Rowid 0 3 000 NULL >7 Column 0 1 400 t.y >8 Column 0 2 500 t.z >9 ResultRow 3 3 000 NULL >10Close 0 0 000 NULL >11Halt 0 0 000 NULL >12Transaction1 0 000 NULL >13VerifyCookie 1 1 000 NULL >14TableLock 1 2 0 t 00 NULL >15Goto 0 3 000 NULL >asql> create index t_x on t(x); >asql> explain select * from t where x=15; >addr opcode p1p2p3p4 p5 comment > - - -- - >0 Trace 0 0 000 NULL >1 Integer151 000 NULL >2 Goto 0 12000 NULL >3 OpenRead 0 2 1 3 00 t >4 MustBeInt 1 10000 NULL >5 NotExists 0 10100 pk >6 Rowid 0 3 000 NULL >7 Column 0 1 400 t.y >8 Column 0 2 500 t.z >9 ResultRow 3 3 000 NULL >10Close 0 0 000 NULL >11Halt 0 0 000 NULL >12Transaction1 0 000 NULL >13VerifyCookie 1 2 000 NULL >14TableLock 1 2 0 t 00 NULL >15Goto 0 3 000 NULL > >-Urspr?ngliche Nachricht----- >Von: sqlite-users-bounces at mailinglists.sqlite.org >[mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von ??? >Gesendet: Montag, 14. Dezember 2015 14:06 >An: SQLite mailing list >Betreff: [sqlite] Is rowid the fastest? > >You said that "You are probably falling into the cache effect trap again. >There is no point in indexing on the primary key, it only wastes space and CPU >cycles ". > I do not agree with you. let me tell you why. > Before I retrieve by index which created for prim
[sqlite] Is rowid the fastest?
You said that "You are probably falling into the cache effect trap again. There is no point in indexing on the primary key, it only wastes space and CPU cycles ". I do not agree with you. let me tell you why. Before I retrieve by index which created for primary key. The speed of retrieve by rowid is very stable(for a long time). Once I retrieve by index , the stable will broken and the speed is faster than its before. I think you could try it. At 2015-12-14 20:58:07, "Hick Gunter" wrote: >You are probably falling into the cache effect trap again. There is no point >in indexing on the primary key, it only wastes space and CPU cycles > >-Urspr?ngliche Nachricht- >Von: sqlite-users-bounces at mailinglists.sqlite.org >[mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von ??? >Gesendet: Montag, 14. Dezember 2015 13:54 >An: sqlite-users at mailinglists.sqlite.org >Betreff: [sqlite] Is rowid the fastest? > >hi, > create a table using the following sql. > CREATE TABLE t(x INTEGER PRIMARY KEY ASC, y, z); > So the x is the alias of the rowid. Retrieving records by rowid around twice > as fast as other indexs values. > Because of the x is the alias of rowid, so retrieving records by x is also > as fast as rowid. Is that right? > > In order to testing the efficiency. After I create index on t(x). > And this give me a suprise, now I retrieve by x , I found that its is faster > than its before. > does retrieve by the rowid the fastest method? > Has creating index on t(x) anything influence to do with the rowid? > > best regards. >___ >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
[sqlite] Is rowid the fastest?
hi, create a table using the following sql. CREATE TABLE t(x INTEGER PRIMARY KEY ASC, y, z); So the x is the alias of the rowid. Retrieving records by rowid around twice as fast as other indexs values. Because of the x is the alias of rowid, so retrieving records by x is also as fast as rowid. Is that right? In order to testing the efficiency. After I create index on t(x). And this give me a suprise, now I retrieve by x , I found that its is faster than its before. does retrieve by the rowid the fastest method? Has creating index on t(x) anything influence to do with the rowid? best regards.
[sqlite] Is rowid the fastest?
??? wrote: > CREATE TABLE t(x INTEGER PRIMARY KEY ASC, y, z); > > In order to testing the efficiency. After I create index on t(x). > And this give me a suprise, now I retrieve by x , I found that its is > faster than its before. An index entry is smaller than a table row, so if you want to read only the values in the x column, searching in the index is likely to be faster then searching the rowid in the table, because less I/O needs to be done. This is called a covering index. Regards, Clemens
[sqlite] Is rowid the fastest?
Does it revert back to slower speed after dropping the index? Can you compare the EXPLAIN output produced with and without the index? There is no difference on my machine (Version 3.7.14); if yours behaves the same way then whatever changes speed is definitely not because SQLite is doing something differently. asql> create temp table t (x integer primary key asc, y,z); asql> .explain asql> explain select * from t where rowid=15; addr opcode p1p2p3p4 p5 comment - - -- - 0 Trace 0 0 000 NULL 1 Integer151 000 NULL 2 Goto 0 12000 NULL 3 OpenRead 0 2 1 3 00 t 4 MustBeInt 1 10000 NULL 5 NotExists 0 10100 pk 6 Rowid 0 3 000 NULL 7 Column 0 1 400 t.y 8 Column 0 2 500 t.z 9 ResultRow 3 3 000 NULL 10Close 0 0 000 NULL 11Halt 0 0 000 NULL 12Transaction1 0 000 NULL 13VerifyCookie 1 1 000 NULL 14TableLock 1 2 0 t 00 NULL 15Goto 0 3 000 NULL asql> explain select * from t where x=15; addr opcode p1p2p3p4 p5 comment - - -- - 0 Trace 0 0 000 NULL 1 Integer151 000 NULL 2 Goto 0 12000 NULL 3 OpenRead 0 2 1 3 00 t 4 MustBeInt 1 10000 NULL 5 NotExists 0 10100 pk 6 Rowid 0 3 000 NULL 7 Column 0 1 400 t.y 8 Column 0 2 500 t.z 9 ResultRow 3 3 000 NULL 10Close 0 0 000 NULL 11Halt 0 0 000 NULL 12Transaction1 0 000 NULL 13VerifyCookie 1 1 000 NULL 14TableLock 1 2 0 t 00 NULL 15Goto 0 3 000 NULL asql> create index t_x on t(x); asql> explain select * from t where x=15; addr opcode p1p2p3p4 p5 comment - - -- - 0 Trace 0 0 000 NULL 1 Integer151 000 NULL 2 Goto 0 12000 NULL 3 OpenRead 0 2 1 3 00 t 4 MustBeInt 1 10000 NULL 5 NotExists 0 10100 pk 6 Rowid 0 3 000 NULL 7 Column 0 1 400 t.y 8 Column 0 2 500 t.z 9 ResultRow 3 3 000 NULL 10Close 0 0 000 NULL 11Halt 0 0 000 NULL 12Transaction1 0 000 NULL 13VerifyCookie 1 2 000 NULL 14TableLock 1 2 0 t 00 NULL 15Goto 0 3 000 NULL -Urspr?ngliche Nachricht- Von: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von ??? Gesendet: Montag, 14. Dezember 2015 14:06 An: SQLite mailing list Betreff: [sqlite] Is rowid the fastest? You said that "You are probably falling into the cache effect trap again. There is no point in indexing on the primary key, it only wastes space and CPU cycles ". I do not agree with you. let me tell you why. Before I retrieve by index which created for primary key. The speed of retrieve by rowid is very stable(for a long time). Once I retrieve by index , the stable will broken and the speed is faster than its before. I think you could try it. ___ 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 attachme
[sqlite] Is rowid the fastest?
You are probably falling into the cache effect trap again. There is no point in indexing on the primary key, it only wastes space and CPU cycles -Urspr?ngliche Nachricht- Von: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von ??? Gesendet: Montag, 14. Dezember 2015 13:54 An: sqlite-users at mailinglists.sqlite.org Betreff: [sqlite] Is rowid the fastest? hi, create a table using the following sql. CREATE TABLE t(x INTEGER PRIMARY KEY ASC, y, z); So the x is the alias of the rowid. Retrieving records by rowid around twice as fast as other indexs values. Because of the x is the alias of rowid, so retrieving records by x is also as fast as rowid. Is that right? In order to testing the efficiency. After I create index on t(x). And this give me a suprise, now I retrieve by x , I found that its is faster than its before. does retrieve by the rowid the fastest method? Has creating index on t(x) anything influence to do with the rowid? best regards. ___ 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.
