June 18, 2009 at 11:33 am
Grant Fritchey (6/18/2009)
Scotch... and beer. Or beer... and scotch.Single malt (Highland or Orkney) followed by a good ESB... ah, makes life worth living.
I rarely drink anymore, but when I do, I am partial to Merlot. I usually like Chatuea Larose Trintaudon which is inexpensive though very nice and generally availble here in the U.S. 😉
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
June 18, 2009 at 11:46 am
There is a tradition in contract bridge, that if you win the last trick of a hand with the 7 of diamonds, your partner must buy you a beer.
SQL = Scarcely Qualifies as a Language
June 18, 2009 at 12:23 pm
Carl Federl (6/18/2009)
There is a tradition in contract bridge, that if you win the last trick of a hand with the 7 of diamonds, your partner must buy you a beer.
Really? Nobody ever made that offer to me back when I was playing! :angry:
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
June 18, 2009 at 12:26 pm
I rarely drink alcohol. Maybe a wine cooler or two on New Years Eve, else wise our house is relatively dry, by choice.
June 18, 2009 at 1:04 pm
I have to get serious again for a moment and stop talking about beer...
I thought that Profiler in 2005/2008 Showplan XML would show the actual execution plans. It's not. It's showing the same thing that querying the plans out of cache using the DMV shows. I really should read the BOL more closely... Hey, it doesn't say anything in the BOL. Not that I can see.
Does that mean the ONLY place to see an actual execution plan is by collecting them Management Studio?
"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
June 18, 2009 at 1:12 pm
Nope. Never mind. I was wrong (again). Showplan XML Statistics Profile does include the actual execution plan. Whew. I feel a little better now.
"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
June 18, 2009 at 1:29 pm
Grant Fritchey (6/18/2009)
Nope. Never mind. I was wrong (again). Showplan XML Statistics Profile does include the actual execution plan. Whew. I feel a little better now.
Just tried with Profiler:
Estimated Execution Plan:
SET SHOWPLAN_XML ON
go
SELECT TOP(10) * FROM Tally
go
SET SHOWPLAN_XML OFF
go
Actual Execution Plan
SET STATISTICS XML ON
go
SELECT TOP(10) * FROM Tally
go
SET STATISTICS XML OFF
go
Flo
Edit: Oups... Already fixed, wrong post... :w00t:
Sorry
June 18, 2009 at 4:00 pm
Lynn Pettis (6/18/2009)
I rarely drink alcohol. Maybe a wine cooler or two on New Years Eve, else wise our house is relatively dry, by choice.
[font="Verdana"]I go through a bottle of wine about every two weeks, and I drink socially (so add another glass or two to that.) By no means a heavy drinker, but I enjoy the taste.[/font]
June 18, 2009 at 6:34 pm
Apologies to all... I got the SUM() OVER thing exactly backwards. PARTITION BY is the only part of the OVER clause that can be used. What I'd like to see is the best of both worlds on such aggregates. If you only do a PARTITION BY, have it work the way it currently works... a single total for all rows returned for that partition split for any given query. Barry was correct. The thing that's missing is the ORDER BY part and I'd like to see it do a running total if the ORDER BY were used.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 18, 2009 at 6:50 pm
[font="Verdana"]I'm guessing that the ISO SQL group weren't thinking of calculating running totals when they defined the windowing version of SUM(). If they add that capability though, it could also mean you could get running minimums, maximums and averages -- could be quite useful.[/font]
June 18, 2009 at 6:56 pm
Bruce W Cassidy (6/18/2009)
[font="Verdana"]I'm guessing that the ISO SQL group weren't thinking of calculating running totals when they defined the windowing version of SUM(). If they add that capability though, it could also mean you could get running minimums, maximums and averages -- could be quite useful.[/font]
I'm not sure, but I believe that it is included in the ISO standard and, if I remember correctly, SUM() OVER in Oracle will produce a running total.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 18, 2009 at 7:42 pm
Well outside of conferences I go throw < a case of beer a year and 3-4 bottles of wine, but I will have a few tonight. Came home to a dog in my daughter's room, a dead guinea pig, another one missing, and fortunately my girl at her aunt's.
I am not looking forward to breaking the news tomorrow.
June 18, 2009 at 8:04 pm
I must have made a mistake somewhere on my PASS abstract submittals. I've gotten no email for either acceptance or denial.
I'll send them an email and see what's up.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 19, 2009 at 3:06 am
Jeff Moden (6/18/2009)
Apologies to all... I got the SUM() OVER thing exactly backwards. PARTITION BY is the only part of the OVER clause that can be used. What I'd like to see is the best of both worlds on such aggregates. If you only do a PARTITION BY, have it work the way it currently works... a single total for all rows returned for that partition split for any given query. Barry was correct. The thing that's missing is the ORDER BY part and I'd like to see it do a running total if the ORDER BY were used.
I think a bit more than just ORDER BY would be needed. Some of the things Itzik discusses (and this is just example syntax) is the ability to specify over what portion of the window the aggregate should run over, controlled by the order by.
So, some examples of this:
SUM(SomeValue) OVER (PARTITION BY GroupingValue ORDER BY SomeDate BETWEEN Unbounded Below and Current Row) -- A standard running total
SUM(SomeValue) OVER (PARTITION BY GroupingValue ORDER BY SomeDate BETWEEN Current Row and Unbounded Above) -- The opposite way around
AVG(SomeValue) OVER (PARTITION BY GroupingValue ORDER BY SomeDate BETWEEN Current Row -2 and Current Row +2) -- A rolling average over 5 rows
etc...
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 15 posts - 5,836 through 5,850 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply