Updated results against current trunk: CPU Time: user 82.009726 sys 129.636831
I rerun the profiler and looked at the results. Most of them looked sensible, but one thing still struck me. Once the new index is created in the VDBE Sorter it gets copied back into the new Btree using a loop with the following OPCodes: sqlite3VdbeAddOp2(v, OP_SorterData, iSorter, regRecord); sqlite3VdbeAddOp3(v, OP_IdxInsert, iIdx, regRecord, 1); sqlite3VdbeChangeP5(v, OPFLAG_USESEEKRESULT); The OPFLAG_USESEEKRESULT is no-op in this case since OP_IsUnique is never used in the merge-sort branch of code. OP_IdxInsert always seeks for the new Btree row in the resulting tree. Couldn't we exploit the fact that the rows are already sorted to construct the Btree faster? Best regards, Filip Navara _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
