Viewing 15 posts - 43,801 through 43,815 (of 59,063 total)
Heh... oh my... :hehe: I believe I've found the secret as to why Cross Apply makes the Tally table solutions run so fast. It forces an unnatural ORDER...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 10:26 pm
Peter,
Sorry man. I tested against 1000 lines of 800 comma separated random numbers each in a VARCHAR(8000) environment... your code did the split into a table at a minute...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 10:16 pm
Phil Factor (5/1/2009)
...but their developers seem unable to fix things so they work like they used to.
Ouch.
They're doing all they can to put in a better solution ASAP. The problem...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 9:31 pm
Peter,
How do I determine what the optimal sector size in your splitter code should be?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 8:32 pm
Sorry, Peter... I got it. You were talking about the code in the previous post.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 8:06 pm
peter (5/5/2009)
Thanks for the information Jeff...care to take a quick look at what your string splitter evolved into as well?
Sorry Peter... I'm out of coffee and I'm not sure of...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 7:57 pm
Sorry, Phil... the proc you attached came out as one huge line. I won't even start to look at something like that.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 7:44 pm
The artical that Paul White pointed us to about the peformance difference between SELECT and SET is pretty close to spot on percentage wise. I'm just not one to...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 7:30 pm
Barkingdog (5/9/2009)
1. Temp 550GB was not enough. t-sql job ran into 550GB limit and failed.
2. Found statement causing the issue. The essence is shown below:
insert into
..
select distinct ....
....
from
tableA join...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 6:22 pm
Wow... that's a heck of a table. I am so not jealous of either that or the rigors they seem to be putting you through.
Thanks for the...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 9:55 am
Manie Verster (5/9/2009)
You only put A-Z and not also a-z. How does that work?
Peter gave a pretty good description as to why. To simplify, the default for SQL Server...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 9:23 am
Florian Reischl (5/9/2009)
Jeff Moden (5/9/2009)
BTW - It is good to see growing acceptance of the idea that ANSI standards are kinda 'blah'. I couldn't agree more 🙂
Man, I agree...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 8:52 am
John Esraelo (5/9/2009)
have not we have had kicked this dead horse plenty..I think we did..
:))
The bones of these types of dead animals are interesting... its especially interesting to see how...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 7:57 am
Paul White (5/9/2009)
Jeff Moden (5/8/2009)
Paul White (5/8/2009)
When assigning multiple variables from constants, SELECT is significantly quicker than separate SET statements.
Heh... I agree, but where's the code to prove that? ...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 7:53 am
Paul White (5/8/2009)
John,When assigning multiple variables from constants, SELECT is significantly quicker than separate SET statements.
Just adding that for completeness.
Paul
Heh... I agree, but where's the code to prove that? ...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2009 at 8:00 pm
Viewing 15 posts - 43,801 through 43,815 (of 59,063 total)