I have not done this, but if you have enough RAM available, you might
try putting your primary keys in a table in an in-memory database, and
test for existence there. That would allow you to enforce uniqueness
while postponing creation of the PK index on the disk table until after
the initial
> Also it's quite known that
> creating index after inserting all rows is much faster than creating
> index before that. So it can be even beneficial in inserting huge
> amount of rows somewhere in the middle of the work: first delete all
> indexes, then insert rows, then create indexes once more.
First of all you should write to sqlite-users mailing list, not sqlite-dev.
> Why is the indexing so slow and bogs down as we proceed with insertions ?
> Any suggestions ?
> Also, how could I improve performance ?
I can't say exactly why performance with index degrades so
significantly with the s
3 matches
Mail list logo