Doesn't sound quite right to me. No matter the index you have to search through it to find the spot to do the insert. Both are going to do that search only once. An insert on a unique index isn't going to search through it for existence, then promptly forget what it just did and do it all over again to do the insert. It's going to start the insert and find the spot where the new item would go. If the spot's free it succeeds, if it's taken then it fails. There is no need for a second search.
-----Original Message----- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Keith Medcalf Sent: Monday, July 30, 2018 3:19 PM To: SQLite mailing list Subject: Re: [sqlite] Sqlite Sharding HOWTO >> A query doing a single insert of a few bytes with no Indexes, no >> triggers, no functions will be stupendously fast, whereas any >> increase in one or more of the above will slow things down. >> How much exactly is something you need to test, any guesswork >> will not be useful. What I can say is that if you don't have >> any Unique Indexes or triggers, the insert speed /should/ not >> change much with size. >I see, thanks for the heads up. What's with Unique Indexes though? >Why are they any worse than a regular index? All are indexes are unique indexes because the rowid is appended to the end of the key (so the original row can be found) thus making every entry unique. For an index that is "unique" in the payload (ie, exclusive of the rowid) a seek of the index must be done on insertion to check for duplicate payloads so that a uniqueness violation can be thrown. This is not required for a non-unique index since the addition of the rowid to the payload ensures uniqueness of the key -- unless the datastore is corrupt, of course, but we will ignore that for now. That is, for CREATE INDEX A on B (C,D) the row can be inserted in the index without checking for a uniqueness violation since the actual key is C, D, rowid. CREATE UNIQUE INDEX A on B (C,D) requires that the key (C, D) be looked up to ensure there is not a uniqueness violation. so for an index declared to be unique an extra b-tree search is required and that takes a wee bit of time ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users