November 27, 2012 at 3:45 am
Hi all
When dealing with the Cost threshold for parallelism, I am almost certain that the Cost is not an amount in seconds but rather a number that SQL Server internally uses.
Is this correct?
I'm asking because I am going through a well-known book and it says: The "cost" is the estimated amount of time in seconds that it would take to execute
Is my understanding wrong?
Thanks
November 27, 2012 at 3:55 am
Hi,
I'm also of the understanding that "cost" is just an arbitrary no.
This link seems to back that up.
Thanks,
Simon
November 27, 2012 at 3:56 am
From MSDN
The cost refers to an estimated elapsed time in seconds required to run the serial plan on a specific hardware configuration
http://msdn.microsoft.com/en-us/library/ms188603(v=SQL.105).aspx
November 27, 2012 at 4:03 am
anthony.green (11/27/2012)
From MSDNThe cost refers to an estimated elapsed time in seconds required to run the serial plan on a specific hardware configuration
http://msdn.microsoft.com/en-us/library/ms188603(v=SQL.105).aspx
From SSC
http://www.sqlservercentral.com/Forums/Topic1287679-146-1.aspx#bm1287938
November 27, 2012 at 4:08 am
I stand corrected.
November 27, 2012 at 4:41 am
anthony.green (11/27/2012)
I stand corrected.
Can I assume that my documentation is incorrect then?
November 27, 2012 at 5:02 am
Yes I would as Gail has mentioned that the documentation on MSDN is incorrect, so anything which says its in seconds is incorrect.
November 27, 2012 at 5:04 am
Yes I would as Gail has mentioned that the documentation on MSDN is incorrect, so anything which says its in seconds is incorrect.
November 27, 2012 at 7:25 am
It's not seconds (anymore). It's a meaningless, unitless number.
It was originally based off of seconds on a specific benchmark machine back when the QO was initially developed, back sometime in the mid 90's
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 28, 2012 at 8:04 am
Just remember that the number is an estimate. This means it can be wildly inaccurate. But, it's the only number you get, so you're going to use it, just don't rely on it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
November 28, 2012 at 10:01 am
Grant Fritchey (11/28/2012)
Just remember that the number is an estimate. This means it can be wildly inaccurate. But, it's the only number you get, so you're going to use it, just don't rely on it.
Thanks
Just my limited experience talking here but I find it weird that MS would change something that we could relate to something that has no meaning.
November 28, 2012 at 10:22 am
SQLSACT (11/28/2012)
Grant Fritchey (11/28/2012)
Just remember that the number is an estimate. This means it can be wildly inaccurate. But, it's the only number you get, so you're going to use it, just don't rely on it.Thanks
Just my limited experience talking here but I find it weird that MS would change something that we could relate to something that has no meaning.
Yeah, to a degree I agree, but, when you consider that the number can't possibly be a real measure of anything because your system is different than mine. Unless you also build the optimizer to literally measure performance metrics first (a possibility I suppose) and then use those metrics in it's calculations, the numbers can never have literal meaning for you or me. So, once you accept that they're just tics or marks or tags, it's easy to work with them without worrying about the fact that once upon a time, they were an actual measure of time (or at least pretended to be).
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
November 28, 2012 at 10:22 am
SQLSACT (11/28/2012)
Just my limited experience talking here but I find it weird that MS would change something that we could relate to something that has no meaning.
They haven't.
The cost has never had a meaning other than being an estimate of the relative expense of queries. A query with a cost of 10 is probably going to take longer and more resources to run than a query with a cost of 1. That's all the cost tells you. It's all the cost has ever told you.
Costs are estimates, they've always been estimates.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply