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
