Five SQL Server 2022 T-SQL Functions You Should Be Using Right Now

Question

Post reply

Five SQL Server 2022 T-SQL Functions You Should Be Using Right Now

vgupta

SSC Enthusiast

Points: 106
More actions
May 29, 2026 at 12:00 am

#4818853

Comments posted to this topic are about the item Five SQL Server 2022 T-SQL Functions You Should Be Using Right Now

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Site Owners SSC Guru Points: 80224 More actions · Answer 1

Thanks for posting your issue and hopefully someone will answer soon.

This is an automated bump to increase visibility of your question.

Jeff Moden SSC Guru Points: 1004725 More actions · Answer 2

First and foremost, great article. Thanks for taking the time to put it together.

A bit interesting on the Tally Table reads. I agree that it does cause reads but that's also one of the reasons why Itzik Ben-Gan created his famous GetNums() function and I created a similar fnTally() function, both of which are READLESS.

Even more interesting that you said the million row Tally Table cause 1.4 GB of buffer pool to be formed... I'll I'm going to have to look into that because the table itself is only 12.594 MB, which is more than a thousand times smaller.

Also, be aware... If you use the GENERATE_SERIES() function as a pseudo-cursor "row source" to create large tables (test or otherwise), GENERATE_SERIES() breaks "Minimal Logging" if you use it. You can read about that in the following article.

https://www.sqlservercentral.com/articles/generate_series-breaks-minimal-logging

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
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.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

fahey.jonathan Hall of Fame Points: 3679 More actions · Answer 3

This is a quick reply to Jeff. I think 1.4 GB divided by 12.594 MB is closer to 111 than 1000. Did I miscalculate? I agree with your central point that the memory allocation seems excessive for the data.