Re: SQL optimize for only writes

Further update:

I added back the 400,000 records (actually now I'm testing with 4 million records). and I am adding 50 records at a time (albeit in the
green screen SQL window) and I am not seeing ANY slowdown (average of .042000 seconds)



I am going to have to develop some test on our browser side to see what the slow down is...



Gqcy wrote:

I just ran the statement in green screen SQL:
insert into kidslib/dcsinpf (dcsrspons,dcstrstat,dcsline,dcsport,dcs
record,dcstrcode,dcstrndta,dcswrkday,dcsshift, dcsrcode,dcsunused,dc
smaint,dcsclkon,dcsclkof,dcscodate,dcsctsmp,dcspflag,dcsptsmp)
VALUES('N','01','U','U',00000,'03','00006000005509012702701655934870
040',00,'U','U','UUU',' ',0000,'UUUU','UUUUUU','2009-01-01-00.00.00.
310508','Y','2009-01-01-00.00.00.325999')

Visual explain still shows the table scan, and I see there is a "Table Scan Reason Code" of "No indexes exist"

G

Walden H. Leverich wrote:

at peak times I am doing "dozens" of writes at once.
...When we had 450,000 records in the file, at peek times, we see the writes queue up.

Insert speed should be independent of the number of rows in a table,
you're just dropping data on the end of a heap. Do you have a capture of
the actual SQL statement that ran to do the inserts? Also, how did you
see the writes "queue up"? If there is a table scan occurring during an
insert then I'd say it's reportable to IBM as a (severe) bug. But I
don't think that's the case, something else is going on. Perhaps you're
trying to get the next# to use as a max(#) or something like that?
-Walden