Apologies for missing your question on this.
Yes, it's possible to work it out from historical information as you've said but it's still pretty much of a SWAG simply because you can't control what else is happening on your server. For example, a rebuild of a given index might normally take X minutes but, if someone has a lock on the index for some reason, the rebuild won't even start until that lock clears up. Even if you rebuild the index "ONLINE", the activity in the table may impact the index rebuild in that it needs to update that "update" table when such online actions occur. Even if you're the only one using the entire database, if something like a backup occurs, that will impact the rebuild.
So, the bottom line is that you can make a guess based on things like history, column widths, column types, etc but there is so much that could affect the amount of time to do a REBUILD or REORGANIZE that the guess could be wildly different that what actually happens even if the index isn't a part of what else is happening.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
"If "pre-optimization" is the root of all evil, then what does the resulting no optimization lead to?"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)