Hello,

1) retailmemberid is INT data type, 4 in length

2) the complexity involves other table relationships, which perhaps explains the delay; the delete perhaps has to ensure that records in the...

1) retailmemberid is INT data type

2) Execution plan shows a complex layout:

delete<-assert<-nested-loop-left-semi-join(0)<-table spool<-assert<-nested-loop-left-semi-join(1)<-nested-loop-left-semi-join(2)<-nested-loop-left-semi-join(3)<-nested-loop-left-semi-join(4)<-nested-loop-left-semi-join(5)<-nested-loop-left-semi-join(6)<-nested-loop-left-semi-join(7)<-table-delete<-index-seek

(0) table-scan

(1) table-scan

(2) index-seek

(3) table-scan

(4)-(7) index-seek

Hope all the above details helps explain things?

Dan

Hello,

Does it make sense to index a primary key column (retailmemberid)?  I tried that with and without indexing and it did not appear to make any difference.... as far as...

Robert,

Thanks for confirming my suspictions, that

indexing is the answer! I ran the MS Index Wizard, and clustered indexed the columns on the rm_vert_subvert tables, and viola! Runs like...