On 19 September 2011 19:25, Simon Slavin <slav...@bigfraud.org> wrote:
> > On 19 Sep 2011, at 7:13pm, Jaco Breitenbach wrote: > > > While on the topic of performance, I've performed a test in which new > tables > > were created within an active transaction (manual 'partitioning') and > > populated within the same transaction. What I've found, was that as the > > number of tables created within the transaction increased, > > You mean 'tables' or 'rows' ? I meant 'tables'. Depending on a configuration parameter up to 1440 tables could dynamically be created within the same transaction within which they are also being populated. If the the tables already existed from a previous execution, they were simply reused (CREATE IF NOT EXISTS ...). If no tables were created within a transaction, the transaction was completed within 1-2s. If tables were also created within a transaction, the speed of record inserts drastically decreased following the table creation (transaction processing time would increase from 2s to several minutes). It must also be noted that any one table creation typically completes within milliseconds, so the time spent on the actual table creation can not account for the total time lost. > > the performance > > of the inserts within the same transaction decreased significantly. I > > haven't spent any further time trying to analyze the cause for this > apparent > > behaviour. > > Because it has to do more work. Inserting the 10,000th record requires > comparing it with 10,000 others to see whether it's a duplicate. Inserting > the 20,000th record requires twice as many comparisons. It's not a linear > function, since the comparison is done by searching a tree rather than a > list, but that's a big component of it. Agreed, but that is not the issue here. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
