July 4, 2009 at 11:06 am
WayneS (7/3/2009)
@Jeff - would you mind trying out this little piece of code and let me know how fast it is on your "computer in a deathbox"?:-D
No problem... would you post the code you used to build the Tally table please?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2009 at 11:13 am
Also, please answer the following questions:
How many time have you had to split something in real production work that actually consisted of more than 8k bytes? What was it for?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2009 at 11:22 am
Last but not least, Wayne... I ran your code and the XML section returns nothing. Perhaps the forum ate some of your code. Can you attach the code, please?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2009 at 11:26 am
Jeff Moden (7/4/2009)
WayneS (7/3/2009)
@Jeff - would you mind trying out this little piece of code and let me know how fast it is on your "computer in a deathbox"?:-DNo problem... would you post the code you used to build the Tally table please?
Sure, but I figured that you had one available...
create table dbo.Numbers (Number int not null)
insert into dbo.Numbers
select top 1000000
row_number() OVER (ORDER BY s1.object_id) AS Number
from master.sys.objects s1, master.sys.objects s2, master.sys.objects s3, master.sys.objects s4
alter table dbo.Numbers ADD CONSTRAINT [PK_Numbers] PRIMARY KEY CLUSTERED (Number)
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
July 4, 2009 at 11:27 am
Jeff Moden (7/4/2009)
Last but not least, Wayne... I ran your code and the XML section returns nothing. Perhaps the forum ate some of your code. Can you attach the code, please?
Never mind my last... I was able to get the complete code by quoting your post.
I'd still like to see your code for the Tally table creation and still like to know how many times and what the purpose of you actually needing to split more than 8k characters in a production environment was.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2009 at 11:27 am
Jeff Moden (7/4/2009)
Also, please answer the following questions:How many time have you had to split something in real production work that actually consisted of more than 8k bytes? What was it for?
Once. A SSRS report with a multi-select parameter that could potentially have > 30,000 items in it. I argued against it, but the PM won... 🙁
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
July 4, 2009 at 11:39 am
Jeff Moden (7/4/2009)
Last but not least, Wayne... I ran your code and the XML section returns nothing. Perhaps the forum ate some of your code. Can you attach the code, please?
See attached. I added to it to build the tally table in AdventureWorks also.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
July 4, 2009 at 12:05 pm
WayneS (7/3/2009)
And, just to be complete, I ran this test again including Lynn's CTE method (DelimitedSplit):XML: 1571/1100/1350/1134/1130
Tally: 1429/1313/1306/1317/1288
CTE: 6283/6221/6292/6445/6569
Heh... looks like the Tally table won twice there.
But, I agree... joining to a VARCHAR(MAX) is comparatively slow. That's why I'm asking how many times someone actually needs to split something more than 8k bytes in length.
Thanks for the testing ideas, though... I've got a couple of different things I've been trying and this adds to those.
As you requested, on my old box, the Tally table gets beat by about 10% in the CPU department, as you would suspect it would. Here's the run...
---- XML ----
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 1 ms.
SQL Server Execution Times:
CPU time = 938 ms, elapsed time = 990 ms.
(31465 row(s) affected)
SQL Server Execution Times:
CPU time = 1500 ms, elapsed time = 3380 ms.
(EDIT: Total CPU = 2438, Total Elapsed = 4370)
---- TALLY ----
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 1 ms.
(31465 row(s) affected)
SQL Server Execution Times:
CPU time = 2703 ms, elapsed time = 4233 ms.
(EDIT: Total CPU = 2703 , Total Elapsed = 4233)
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2009 at 12:07 pm
WayneS (7/4/2009)
Jeff Moden (7/4/2009)
WayneS (7/3/2009)
@Jeff - would you mind trying out this little piece of code and let me know how fast it is on your "computer in a deathbox"?:-DNo problem... would you post the code you used to build the Tally table please?
Sure, but I figured that you had one available...
create table dbo.Numbers (Number int not null)
insert into dbo.Numbers
select top 1000000
row_number() OVER (ORDER BY s1.object_id) AS Number
from master.sys.objects s1, master.sys.objects s2, master.sys.objects s3, master.sys.objects s4
alter table dbo.Numbers ADD CONSTRAINT [PK_Numbers] PRIMARY KEY CLUSTERED (Number)
I absolutely do have my own code for a Tally table. I just wanted to make sure that yours had a Clustered PK on it because a lot of folks forget that. Thanks, Wayne.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2009 at 12:16 pm
Jeff Moden (7/4/2009)
... I just wanted to make sure that yours had a Clustered PK on it because a lot of folks forget that. Thanks, Wayne.
Ahh, now I understand your strange request. 😉
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
July 4, 2009 at 12:26 pm
Jeff Moden (7/4/2009)
...Thanks for the testing ideas, though... I've got a couple of different things I've been trying and this adds to those.As you requested, on my old box, ...
Thanks for doing this Jeff! And I'm glad I could give you something else to try out...
I do agree that both the Tally table and the pseudo-tally table (CTE) method are excellent methods, esp. when dealing with smaller strings than what I threw at it. And any of these three methods is preferable to any cursor / looping method out there. I was shocked at how much slower the CTE method was when I threw the large string at it... I tested it expecting it to be nearly as competitive as the tally table was.
Thanks again for your testing.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
July 4, 2009 at 12:36 pm
You bet, Wayne. Thanks for answering my seemingly unrelated questions. They go far in helping me understand the needs of folks so I can setup certain tests for certain scenarios.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2009 at 2:58 pm
Jeff Moden (7/4/2009)
You bet, Wayne. Thanks for answering my seemingly unrelated questions. They go far in helping me understand the needs of folks so I can setup certain tests for certain scenarios.
No problem. The Tally table one threw me... heck, I got it from you in the first place! And asking the business reason for something weird (in this case, a comma-delimited string of > 30,000 items definitely qualifies) is fair... and another pair of eyes can often provide an alternate solution for what's being done.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
July 4, 2009 at 6:46 pm
Here is another tab split function that I pulled from a SQL 2000 book by Andrew Novick : Transact SQL UDFs
Which is better Lynns or Andrews ??? 😎
July 4, 2009 at 7:10 pm
Digs (7/4/2009)
Here is another tab split function that I pulled from a SQL 2000 book by Andrew Novick : Transact SQL UDFsWhich is better Lynns or Andrews ??? 😎
We've given you the ability to do your own testing. Test it and report back to us. 😉 You might also want to actually read the rest of this thread because, as good as it is, the Base 10 CTE isn't the one you should be comparing performance against.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 31 through 45 (of 70 total)
You must be logged in to reply to this topic. Login to reply