Press "Enter" to skip to content

Category: Temp Tables

The Yin and Yang of Temp Tables

Deborah Melkin covers the gamut:

My stance is that temp tables are a useful tool when properly used, but they’re very easy to misuse to the point of creating problems. Table variables are even more misused for similar reasons; that could be a whole other blog post that almost starts and ends with “they’re not variables stored in memory but just regular temp tables without stats.”

Click through for examples in which temp tables have been quite helpful, and cases in which temp tables have been actively harmful.

Leave a Comment

The Temp Table of Last Resort

Louis Davidson shares an approach:

Temp tables fit into my query writing process as one of those last ditch efforts to make a query execute fast enough. Of course it would have been harder if I had followed all the rules and added a lot of test cases, but I had a pretty busy week last week and am finishing this pretty late on Tuesday night, so I just gave my opinions.

I like Louis’s strategy. It’s easy to add a lot of complexity to queries out of habit, to micro-optimize performance, or because of a meandering thought process. But many times, taking a step back to think about what could make a query simpler will be helpful.

One thing I’ll cover that Louis didn’t touch on is that performance level is (or should be) a requirement. If you have a query running millions of times a day on a system, then yes, it makes sense to squeeze out every microsecond. But for an ELT job that finishes in 20 minutes and where you have a 6-hour window to get the data loaded, shaving five minutes off of the query’s runtime isn’t that important, especially if you’re in read-committed snapshot isolation or using another form of optimistic concurrency.

This is why I recommend starting with simple and only moving to more complex solutions when you need them. Now, do I always follow my own advice? Err…well, the sign pointing to Boston doesn’t have to go there itself…

Leave a Comment

Comparing Temp Tables to Table Variables

Marlon Ribunal compares two techniques:

For this post, I needed to do some research because there is more to #temp tables than simply creating one and using it. As I started digging into the topic, I realized there are a lot of discussions around #temp tables and @table variables, especially around when one might be a better choice over the other.

One of the common arguments is that #temp tables go to disk while @table variables stay in memory. Another argument is that this is a myth. That got me curious about what the actual differences are and when they really matter. Discussions like this almost always starts with where the data is stored (disk vs memory).

Yeah, the “table variables are just in memory” is a myth, at least for normal table variables. Memory-valued user-defined table types do change things, as they don’t use tempdb. But they come with their own set of handcuffs.

Leave a Comment

Choosing between Temporary Data Options

Chad Callihan builds a list:

Jeff provides half a dozen prompts to get the ball rolling, and I thought I’d discuss my thoughts on “the whole family. #temp vs. table variables vs. CTEs vs. indexed views. When does each one earn a spot?”

Indexed views are an odd man out. As far as table variables go, there are two places where I really like to use them. First is for logging, because they survive a transaction rollback, so even if you roll back your transaction in a catch block, you can still insert that vital error information into a logging table. Second is for table-valued parameters in stored procedures, though that does require a user-defined table type versus an ad hoc table variable.

Leave a Comment

Temp Tables and Stored Procedures

Shane O’Neill breaks a stored procedure:

Ages ago, I broke one of the stored procedures in Brent Ozar‘s First Responder Kit.

I filed that feat under the heading “Cool; Good to Know“, and then promptly forgot about it. Part of me thinks that I forgot about it because I didn’t understand how I accomplished it. While another part is sure I forgot about it cause “good to know” wasn’t on the list of tasks with looming deadlines.

I’m a man of many parts, but of more deadlines. Now, let’s understand it together!

Click through to see how. Also, when Shane refers to finding Wally, we in North America know him as Waldo. That’s how hard to find he is: he changes his name depending on the continent.

Leave a Comment

The Nuances of Using Temp Tables

Rob Farley explains a position:

Let me say for starters that I’m pleased we have temporary tables. They’re tremendously useful, but often get abused. Compared to obvious villains like NOLOCK, cursors, and scalar functions, they’re really quite inane (but any of these features can be used for good – trust me). But temporary tables were the one of these I mentioned in last month’s post about signs of a bad query. If nothing else, using temporary tables probably means you’re writing procedural code rather than set-based queries.

The scenario I want to talk about is using temporary tables to materialise a set of data, ahead of using it in a separate query a moment later. That’s essentially what Jeff Taylor is asking us to comment on.

I agree very strongly with Rob’s position. In stored procedures, temp tables should be there for a specific reason, a resignation that it is a second- or third-best design decision. But sometimes, you need second-best because first-best doesn’t perform well enough.

Leave a Comment

Thoughts on Temp Tables

Andy Brownsword shares an opinion:

For August’s T-SQL Tuesday ask, Jeff has thrown temp tables to the wolves. Does the community like or loathe their usage?

I’ll predict a few ‘it depends’ responses, and I lean towards Jeff’s position that they’re more of the exception than the rule. I’d argue there’s one particular scenario where this exception becomes exceptional (heh).

I imagine that this topic will get a bit of play this month and that it will be a bit more contentious than some might expect. I do like Andy’s scenario of when temp tables become quite valuable.

Leave a Comment

Accelerated Database Recovery in tempdb for SQL Server 2025

Rebecca Lewis looks into a feature:

Two weeks ago I covered the Resource Governor changes in SQL Server 2025 — specifically, capping how much tempdb data space a workload group can consume. That was the data-file side. For the log side, SQL Server 2025 now lets you enable Accelerated Database Recovery (ADR) on tempdb. Enable it and cancelled queries stop grinding, the tempdb log stops bloating, and recovery gets faster. Sounds like an easy yes — but you’ve got to read the fine print.

Click through for that fine print.

Comments closed

Tips for tempdb Resource Governance

Rebecca Lewis shares a few tips:

Someone runs a massive SELECT INTO #temp, tempdb fills the drive, and the entire instance freezes up dead. You get paged at 2 AM, kill the session, shrink the files, and spend the next day writing a monitoring script that you hope will catch it next time.

SQL Server 2025 finally lets you stay ahead of this. The Resource Governor can now cap how much tempdb space a workload is allowed to consume. Exceed the limit and SQL Server kills the query — not the instance. How cool is that? It’s like proactive DBA-ing without the DBA.

Click through for a primer on how to enable Resource Governor, how to alter the default workload group to set a cap on tempdb disk space utilization, and some things to keep in mind if you do use this feature of SQL Server 2025.

Comments closed