Timeline for Improving query to generate a million empty rows
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 16, 2017 at 13:08 | vote | accept | treeNinja | ||
| Aug 15, 2017 at 22:55 | answer | added | Hannah Vernon♦ | timeline score: 2 | |
| Aug 15, 2017 at 20:25 | history | edited | treeNinja | CC BY-SA 3.0 |
included variable examples. The receiptData insert takes the majority of the time, the initial population of @tempT is what takes 30 seconds.
|
| Aug 15, 2017 at 20:14 | history | edited | Jon of All Trades | CC BY-SA 3.0 |
Clarified the breakout of the run time
|
| Aug 15, 2017 at 19:31 | answer | added | markp-fuso | timeline score: 2 | |
| Aug 15, 2017 at 18:30 | comment | added | RDFozz |
An explanation of the relationship between recId and ffid would seem to be in order as well. Why do you need to check if there's an existing record where ffid matches your newly-entered recId and the record number is the one you're trying to add?
|
|
| Aug 15, 2017 at 18:12 | comment | added | Joe Obbish | You have a bunch of undeclared variables in your example code. Can you provide a complete example that we can run without access to your system? That will make it easier for people to help you. Also, can you clarify which part of the procedure is taking the most time? You said that it took over 13 minutes to process but a 30 second step took the majority of the time? How is that possible? | |
| Aug 15, 2017 at 18:01 | history | asked | treeNinja | CC BY-SA 3.0 |