|Subject||Re: Massive INSERT test|
> How selective are your indexes? I.e. will there be lots ofduplicates? If
> you were doing an insert like this, I would assume your best betwould be
> to turn off the indexes during the insert and then turn them backon
> afterwards.Only one indice isn't unique. For the one which isn't I can't answer
the question right now.
However I need the data to be indexed at all times how would I know
if I am not creating duplicates otherwise?
> 10,000 records in 34 seconds sounds too slow - I'm not used to testmassive
> inserts, but selects can manage 10,000 records in 1 or 2 seconds.How are
> you inserting? Parameterized dSQL I presume, but do you useParamByName or
This is my embedded SQL statement:
INSERT INTO myDB (myCols ... ) VALUES( ... )
Not sure if it answers your question.
> Params or whatever (I come from an IBO background)? And what aboutThe data is "fault-tolerant". It is a snapshot of certains processes
> transactions? I assume commit every 10,000 or 20,000 would be OK.
and I can afford a great deal of data loss. Data errors would be
more of a concern of course ...
> >Insert semi-random data benchmark:numbers from
> >2,000,000 0:53 sec
> >2,200,000 1:08
> >2,300,000 1:19
> >2,400,000 1:48
> >2,500,000 1:51
> >2,600,000 2:07
> >2,700,000 2:07
> >2,800,000 2:19
> >2,860,000 4:51
> >2,900,000 4:47
> >ibserver.exe used 40 MB memory at that point.
> >I stopped the test and restarted the service.
> >3,000,000 1:28
> >3,100,000 1:43
> >3,200,000 1:50
> >3,300,000 2:14
> >3,400,000 2:06
> >ibserver.exe is up to 10 MB memory usage at this time.
> Sorry, I don't understand your benchmarks at all. Increasing
> 2,000,000 up to 3,400,000 followed by seconds that mostly, but notIt's the non cumulative time it takes to insert 10,000 rows. The
> exclusively increases as the other number increase??
left figure is the current number of rows in the table.