The key point I was thinking of for keeping that index was that it was perfect for speeding up the foreign key check / subquery for this part. I wasn't thinking at all in terms of unique enforcement.
INSERT OR IGNORE INTO AdAttribute (Type, Value, AdObjectId) VALUES (@Type, @Value, (SELECT Id FROM AdObject WHERE DistinguishedName = @DistinguishedName)); But yeah, keeping track of that in your enveloping program is a option. -----Original Message----- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Olaf Schmidt Sent: Wednesday, May 17, 2017 3:40 PM To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] Bulk load strategy Am 17.05.2017 um 19:08 schrieb David Raymond: > The unique index on DistinguishedName though is what gets used for that sub > query of the insert, so most definitely keep that one index for the whole > load. (The others can be left out until the end though) > I once had a similar scenario, and solved it with good speed - by following Simons suggestion to Drop all indexes first - and then I've "manually ensured Uniqueness" over a DB- independent, normal HashList for fast "Exists-lookups". After the import went through (with about 300000 records/sec), I've freed the HashList and recreated the Indexes on the DB. Not sure though, how many unique "DistinguishedNames" Joseph has to manage in his scenario (risking out-of-memory on the Hash-Container). Olaf _______________________________________________ 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