- Host: Steve Stedman / Mitchell Glasscock
- Topic: The 7 Deadly Sins of Index and Statistics Maintenance
- Recording Date: February 10, 2026
- Listen on Spotify
Stedman SQL Podcast Season 3 Episode 5 The 7 Deadly Sins of Index and Statistics Maintenance
Steve Stedman and Mitchell Glasscock discuss the seven deadly sins of index and statistics maintenance in SQL Server. They highlight common mistakes such as blindly rebuilding or reorganizing all indexes nightly, adhering to outdated 5% and 30% fragmentation rules, and wasting resources on tiny indexes. They emphasize the importance of focusing on statistics over fragmentation, using customized OLA Hallengren scripts, and avoiding over-indexing. They also warn against running aggressive maintenance during peak hours and blindly trusting third-party tools like SQL Server Maintenance Plans and Database Tuning Advisor. The discussion underscores the need for evidence-based maintenance practices to optimize SQL Server performance.
Podcast Transcript:
Steve Stedman 00:16
Welcome back to the Stedman SQL Server Podcast. I’m Steve Stedman from Stedman Solutions, and joining me today is Mitchell Glasscock, welcome Mitch. Hey, Steve. Mitchell is one of the Database Health Monitor developers as well as one of the team members and leads on our Managed Services team. This is season three, episode five of the Stedman SQL podcast, and today, we’re going to tackle something that causes more wasted CPU bloated logs and unnecessarily blocking, as well as performance headaches, than almost anything else. Index and statistics maintenance gone wrong. We’re going to call out what we’ve come up with as the seven deadly sins, the worst things DBAs do or fail to do. Plus, if we’ve got time, maybe three bonus ones to round out to top 10. If your maintenance job is rebuilding everything nightly or running reorganized like it’s free candy, this episode might hurt, but we’ll save your server so quick. Shout out to Database Health Monitor. Consider here for using, for tracking, index, usage, fragmentation, statistics, age, what’s been rebuilt, what hasn’t. And more than just you get from normal blind jobs that are running. So databasehealth.com for a free trial.
So if you’re listening, would you like to be a guest on our podcast. Are you interested in being a guest on the Stedman SQL podcast? If you are just reach out to us and we can talk about what topics, things you want to cover, or talk about anything relating to SQL server, Database Health Monitor or about our company, you can reach out to us at Https://Stedmansolutions.com/guests or go to the podcast page and click on the guest link, fill out the form and find out if you’re going to be a guest on one of our future episodes.
All right, so the Seven Deadly Sins of index and statistics maintenance. So why is this so misunderstood? I think one of the things I see is that there’s a lot of things that have changed over time. So for instance, index fragmentation, I think, is really overhyped on modern hardware, if you’re running on SSDs or sans low page density and stale statistics might cause way more real pain with bad query plans and extra IO than you would get with fragmentation in the old days. And I say that because maybe even days before Mitchell was born. In the old days of SQL Server, there were rules around 5% and 30% rules were, I don’t know, people talked about them as a way to at 30% you should of fragmentation. You should be rebuilding an index, and at 5% you should be reorganizing it. I don’t even know where all that came from, but that was in the documentation way back when, and Microsoft eventually pulled that from the docs because it caused a lot of excess waste.
So here’s the story. We had a client that we’ve worked with, actually several clients that were using one specific medical, medical patient care reporting system, and on these systems, they were, we’re hearing from all of them that, and this is oftentimes a first, a first contact call with them, is that their system would be slowed down or bogged down in the morning, when doctors and nurses were getting started, and then by around 1030 or 11am the system would speed up, and it would all be great running again. Okay, this was so slow that it was slowing down patient care, and it was making it really difficult for doctors to be able to do the job for patients that were being seen at several different medical facilities. Well, it turned out that the software vendor that made the product they were using had turned on full statistics rebuilding on every single table, on every single database, every single night, on every single statistic, on every index, on every table, on every database, every single night, okay, so, and some of these were tables that were huge and what was happening, and the reason that this was so slow through the morning until 1030 or 11am and then two. What some one of them was even noon before it started working fast again, is that that indexing job, the index rebuild and statistics rebuild, would kick off around 1am and it would still be running, and it would finish around 1110, 30 to 11am in the morning. The problem was, while all those indexes and statistics were being rebuilt, they were not online, because this was standard edition, they were not available to be used. So it was like not having some of those indexes or not having some of those statistics there. Well, working with those clients, we were able to find out that exactly what was causing that we were able to modify a few of the RE indexing jobs and get it to the point where their re indexing took an hour to hour and a half every day, instead of 10 to 12 hours every day. That made all the difference in the world for the usability of that system. Some of these were even clients that they came to us after they’d even upgraded their hardware in order to make this faster, and it was still taking just as long. So we’re going to go through some of the details around this and come up with the reasons and some of the background for things that you should not be doing or that you should be doing around rebuilding indexes. So let’s dive into it, the ones that make DBAs look busy while hurting performance.
Mitchell Glasscock 06:27
I think before we jump into it fully, though, I think it’s interesting as someone who’s newer in the SQL Server world. I mean, I’ve been with Stedman Solutions for two years and working with SQL Server for three or four years now, but it’s interesting how many myths and people shouting This is the best practice to do indexes, just indexes in general, that are online. What? What kind of causes this kind of stuff?
Steve Stedman 06:59
I think, Well, I think it really comes down to two things. Number one, misinformation, not malicious misinformation, but just foolish misinformation. And two things changing over time. So for instance, in I think it was 1990 when I use SQL Server for the first time, and the install was like 26 floppy disks, and by the time you got it installed, oh yeah. And if you don’t know what the floppy disks are for some of the younger people, those are what the save icon is. Sort of a joke there I saw from meme lately, but by the time you got it installed on a server that had really slow disks and hardly any memory and hardly any CPU. A lot of these things were had to be done differently because reading a page from disk was a heck of a lot slower then than it is now today. There’s a lot of things that we do very differently than we did back then, also today, and there’s, like, nobody had a terabyte database back then. There just wasn’t that kind of storage. You were lucky to have a 20 megabyte database back then. So a lot of things have changed over time. So back to the question of, like, kind of, why so much out there that’s wrong? Yeah, I think it’s just people getting it wrong and then following rules that were outdated 20 years ago? So something more on that? Mitch, or should we jump into the from, from my point
Mitchell Glasscock 08:29
of view, it just seems like a lot of stuff comes from. It’s, it’s good intention, bad practice.
Steve Stedman 08:35
Yep. So of the Seven Deadly indexing sins, sin number one is blindly rebuilding or reorganizing every index on a schedule. Now that’s what I talked about a minute ago, with the example of the medical clinic that was doing it kicked off at 1am every single night for, yeah, for who knows how long it was, bogging them down until the next morning when it stopped. Whether you’re using SQL server maintenance plans to do that, or whether you’re using the OLA Hallengren style indexing jobs without the right parameters. Simply trying to rebuild everything on any schedule, whether it’s every night or every week, is just a bad way to go, and the reason is that I don’t think I’ve ever seen a system where every single index or statistics had a need to be rebuilt every single night. What you’ve got in your database is you’ve got some tables that are changing frequently, that may need to be rebuilt more often. You’ve got other tables that change very little, and those indexes and statistics may not need to be rebuilt very often at all. So this ends up wasting massive resources, chewing up CPU slowing things down, causing blocking while the things are being rebuilt that don’t even need to be rebuilt, and it’s pointless on a lot of small tables. Is, so that’s the number one Mitch. What are your, have you seen this?
Mitchell Glasscock 10:07
Yeah, new to SQL Server. I’ve seen it. It’s, it’s just bad practice. It’s, and it’s, again, good intentions, bad practice. And then I’m sure we’ve said it on multiple podcasts before, but using the SQL Server index maintenance jobs not a not a fantastic idea, just off the bat, because you don’t get that level of customization you can with scripts like the OLA index maintenance.
Steve Stedman 10:35
Yeah, and I just do want to make one thing clear on what I said about it’s not a good idea to use the OLA scripts without customizing them for your environment. We love the OLA Hallengren scripts. We recommend them. We use them everywhere we can. But we always want to make sure that we get the settings right so we’re doing the right work on that index maintenance. And it’s not to blame Ola or anything on that like that, because everyone has a different environment, but understanding the environment but understanding the environment, understanding what needs to be done, and getting those set right, can make a really big difference in the performance, for sure.
Mitchell Glasscock 11:07
So sin number two, this is one that I this is, this comes from before my time. So that 5% that 30% rule that you, you talked about a little bit earlier, but I’m, I’m curious to learn more what your knowledge of this is.
Steve Stedman 11:21
Yeah, so those were some of the settings that early on the internet people talked about, in the documentation, talked about that’s the settings of when you’re rebuilding or when you’re reorganizing, and if, and I think it was at 5% fragmentation, you should be reorganizing, and at 30% you should be rebuilding Well, the reality is that triggers things way too often, and ignoring the that external fragmentation rarely matters anymore. And basically this leads to what we consider like death by defragmentation. So where we usually go with this is we defragment less often, but we focus on rebuilding statistics more often. If you’re looking at SSD or sand storage today, your IO is so much faster that if you got to bring in a couple extra pages to be able to service a query or load an index or whatever it may be, then, usually that’s not going to make that big of a deal. But if you’re so fragmented that you’ve got to bring in twice as many pages, well, yeah, maybe that’s worth, worth considering, worth rebuilding. So usually we go with much lower levels than that, and depending on the environment, we set it up so that we’re not going to rebuild and reorganize for hours on end. When we do that, usually, I will consider that if a table is more than 80% fragmented, I will consider doing a rebuild. If it’s less than 80% fragmented and more than 30% fragmented, I’ll consider doing a reorg on it. And of course, this may vary slightly, depending on whether you’re standard or Enterprise Edition, but kind of that’s general, general rule there and then. If it’s less than 30% fragmentation, I don’t really care, because it’s not going to make that big of a difference overall in the performance of how your indexes or your tables are working there. Now with that, I think we’ll get to in a minute, is statistics. I want to make sure on these comments I’ve made here, I’m just talking about defragmenting or rebuilding indexes, not talking about statistics necessarily. Yet, on to sin number three, treating reorganization as the safe or preferred option. Now, sometimes it’s better to go do a rebuild than it is to do a reorg. Now, what the rebuild does on Standard Edition is it effectively drops the index and then builds a brand new one. I know it doesn’t look that way, but from the performance perspective, that’s what it’s doing on enterprise. You can do an online rebuild where it effectively builds a brand new index and then swaps it with the existing one. And yeah, there’s some benefits to doing it there, but just saying that I’m going to reorganize all the time and never do a rebuild is not necessarily a smart thing to do, because reorganizing can create more log activity, and it can’t always compact lobs or large objects as well. So there are times to just simply saying reorganizing might not be the right option. So you want to kind of look at that and understand and especially as applies, especially on really, really huge tables. All right. Mitch, what’s sin number four on our list?
Mitchell Glasscock 14:55
So we’re looking at wasting time on tiny indexes. And this kind of goes. Back around that Ola level, or the OLA jobs, being able to customize those jobs and set these parameters so that you’re not wasting resources. So we consider, generally, anything between 1000 to 10,000 pages is going to be considered a tiny index. This, of course, depends on what your actual system is and the index maintenance that you’re handling there, but oftentimes the overhead just outweighs the benefits in this area. So even Microsoft says skip this for a good reason. Yeah.
Steve Stedman 15:39
And the thing is, I mean, those are so small that even if you, even if you’re adding 20 or 30% of excess load to a really small index, it’s not going to make that big of a difference on IO, and a lot of them are being cached in memory anyway when they’re that small.
Mitchell Glasscock 15:52
So unless you’re working with like a super wide table, for some reason, but hopefully your indexes aren’t super wide in that example.
Steve Stedman 15:57
Yeah, of course, hopefully you never have indexes that are super wide. Let’s just put it that way. Okay, so this next one sin number five blanket low fill factors. So here’s the deal with fill factor. Back in the old days when IO was a lot slower than things are today, fill factor was way more important. Because what fill factor was would do is it would say, when you rebuild or create an index to begin with, that it only fills up each data page, 8k chunk of information to a certain level. Some people went 50% others went 80% some went 70% I don’t know, to some level to say, let’s just leave all of those pages half empty so that as more stuff comes along later, we can fill in those pages. Now imagine this, if you had like a journal where you were writing in your journal every single day, and you wanted to leave room on every single page of your journal so that if you thought about something that happened three days ago, you can come back and write it in later. Well, that’s kind of how the fill factor works, is it’s just leaving space so that stuff could be put in there later. Now, from IO from 30 years ago, that was a really, really smart thing to do, maybe not 50 to 70% but at least to fill them at like 80 or 90% in today’s world, there’s no need for that, because index page splits are a lot faster than they used to be back then. If a page fills up, it splits and creates two pages, and the low fill factor really bloats indexes, massively, increasing more IO and memory use and creating a vicious cycle of more splits and more maintenance. Now, for fill factor to actually work, you have to for the fill factor to work correctly on an index, whatever the index keys are, need to be done in a right order that you’re actually going to be filling evenly amongst all those pages and reality that really doesn’t happen very often. So we see this. This is one of those things we catch a lot when we’re doing our managed services. Work on analyzing servers is we find indexes that have a low fill factor, sometimes taking up twice as much space or twice as much IO as they need to. We usually will adjust those fill factors and rebuild them, setting up to 99 to 100% meaning they’re full, and then we end up saving a lot of space and a lot of IO on that. And usually that’s been a boost in overall performance from our experience in doing that.
Mitchell Glasscock 18:39
Does this kind of also play hand in hand with, say, servers from 20 years ago, rebuilding indexes was a much bigger task. So it was the myth kind of perpetuates from avoiding having to rebuild as often.
Steve Stedman 18:56
Oh, yeah, that’s a really good point, because, yeah, I mean, if you’re running on a much slower system that doesn’t have the IO or the horsepower to really rebuild your indexes when they need to be rebuilt, then, yeah, maybe the fill factor could have been more important at that point. Yep, certainly. Okay. Sin number six. This is one of those that I see a lot of the time with new clients and with a little bit of education, we usually get them around this one, and this one is obsessing over fragmentation while ignoring statistics. Now, with what we’ve talked about so far in here, we’ve talked about a fair amount about fragmentation, and hopefully you’re understanding that don’t panic over a little bit of fragmentation and but statistics, in my opinion, are way more important than fragmentation. So what statistics are is, and I always refer to them as cardinality estimates, but they’re basically an analysis of what’s in that index, what’s structured in that index, based off of the values that are stored in the table. Now SQL Server can. Use that when it’s creating a plan to figure out, well, which index am I going to use and am I going to do a scan or a seek, things like that. And if that’s out of date, the query optimizer will be making bad decisions and giving you bad plans that may not run as optimally as they would if it knew what was actually in those indexes. So by updating statistics, it gives SQL Server the best clues as to what’s in those tables and indexes so it can make the right choice on the plans. Now, some systems I’ve worked on, they just have no statistics maintenance, and what that means is that their query plans that are running today may be going off of the size that a table was three or four years ago in determining how it’s going to use that. And SQL server may look at it and say, Gee, that looks like a really small table. Let’s just do a scan on it rather than a seek. And then suddenly things are running a lot slower. So what I like to do is obsess over statistics rather than fragmentations fragmentation and I like to be able to build rebuild statistics every night, if the system permits it. Now that doesn’t mean I’m going to rebuild all of them, because that would be foolish, but you want to look at which statistics are the most out of date if you have a table that has statistics on it and that table hasn’t changed in three years? Well, those three year old statistics might be accurate, but if you have a table that was, I don’t know, 1000 rows in it three years ago, and then today, it’s got 10 million rows in it, well it’s probably using, if it hasn’t been updated in that time, it’s probably using a wrong set of statistics. Wrong set of statistics there to be able to figure out how query plans are going to be used and optimized. So one of the things, and this is another plug for Ola Hallengren scripts, is that with the OLA scripts, you can tell it to only rebuild those that have changes and to not rebuild those ones that haven’t changed. And I also like to put a time limit on it too, so that it doesn’t run forever. And that one change alone on doing statistics rebuilding with the OLA scripts, where you’re only rebuilding those that need to be rebuilt, can make a huge performance difference for your for your environment.
Mitchell Glasscock 22:21
Yeah, that that kind of, that last part where you set the time limit, that kind of leads us into sin number seven, which is running aggressive maintenance during peak hours. It’s just, I mean, not a good idea, like you said at the beginning, we’ve had the clients reach out to us because, hey, everything’s slow in the morning, we don’t know why. And then it’s great in the afternoon. Well, they were running pretty aggressive maintenance during those peak hours and causing those slowdowns.
Steve Stedman 22:50
Yep. And with that, I mean, I’ve seen people schedule like, like I said, with a health clinic that in the very beginning, example, where maintenance is being done at 1am but it runs a lot longer than they expect. That’s why I like to use the time limit on those kind of things to let only let it run for so long. All right, so now a word from our sponsor, Database Health Monitor is your SQL Server slowing down your business, slow queries, bottlenecks and unexpected issues, eating up your time, introducing Database Health Monitor, the powerful tool built by our team at Stedman Solutions, get real time insights into performance with over 100 built in reports, index analysis, weight stats tracking and proactive alerts, quickly diagnose and find problems before they impact your operations with an easy to use interface for DBAs and developers, monitor unlimited servers, tune queries and keep your databases running healthy and fast. Download a free trial today Databasehealth.com and take control of your SQL server performance.
Steve Stedman 24:03
So just a quick note on Database Health Monitor, yeah, there’s a bunch of indexing reports in there, but if you look at the quick scan report and Database Health Monitor, it will catch a number of these sins that we’ve been talking through here, and it will report on them and let you know about them. So plus, for our managed service customers, that’s caught in our daily monitoring scripts as well, so we know about it, so we can get it fixed so your system can run as fast as it can. Okay. So on to that seven. We’ve hit seven deadly sins. On to the three bonus or honorable mentions bonus. Number eight, you want to take that one Mitch.
Mitchell Glasscock 24:41
So this is another one of those myths that I see kind of perpetuating an online DBA culture. You might call it, but over indexing on everything. A lot of people call it out. A lot of people don’t know what it really means, but people read online that indexes are great. Thing to add to your system, which they are, but you can easily add way too many indexes to a table to a database, and this causes job slowdowns. This causes poor query performance by wrong selections of indexes through the query plan optimizer. It can just lead to a large slew of problems by over indexing?
Steve Stedman 25:24
Oh yeah for sure. And on that one I can remember, oh gosh, must have been 15 years ago, I was at a conference, and somebody was talking about indexing, then I was listening and learning, and someone in the crowd at the end, it’s Q and A time, they raised their hand and said, Hey, how many indexes can I put on a table? And I think the answer at that point in time, I think was around 1000 to 1024, I think the number is higher. Now, I don’t know, but the thing is, I don’t care. And here’s the reason, I don’t care how many indexes you could put on the table, because the answer should be way more than you ever should. And some people ask them that, well, how many is too many on a table? Well, back to the old DBA response and things like that. It depends. It depends on a lot of things. It really depends on how big that table is. What are the things you’re indexing? Are all of those indexes actually being used and helping you is the number of indexes that you have on that table so great that it’s slowing down, inserts, updates and deletes. Those are all the things you need to answer the question of how many, oh, you should never ask that. It’s way more than you should ever, ever even consider doing. I don’t know. I think that. I mean, there’s kind of the rule of thumb any more than, like, maybe a dozen, I start to really get concerned or look into why. But then again, there’s some environments I’ve worked on where, because of a poorly organized or created table, they needed to have 30 or 40 indexes on it. Maybe that should require a table redesign, not just looking at how many indexes you can put on there.
Mitchell Glasscock 27:01
Yeah. And this is another shameless plug for Database Health Monitor. The unused Index report is a great way to see, hey, I’m looking at 50 indexes on one table. How many are actually being used?
Steve Stedman 27:11
Yeah. And you know, last year, we made a modification of that unused indexes report that actually tracks that information over time. So when you look at the unused indexes report, you can go back and look, if you’re keeping a year worth of historic data there, has that index even been used in the last year, rather than just hasn’t been used since the last time the SQL Server was restarted, which is what most of the DMVs will give you, all right, the second bonus one, or the deadly sin number nine, never touching or indexing stats on large, write heavy tables. What this means is that where you’ve got a big table that is very frequently being written to taking a do nothing extreme, where you’re you don’t want to index it, or you’re afraid to index it because it’s so big, or there’s so much activity going on there? Well, you’re eventually going to have to access the data and having some indexes around. I mean, it’s, it’s like the whole Goldilocks story. You don’t want it too hot or too cold. You want it just right. And on the number of indexes, you don’t want to over overdo it, but you don’t want to have zero either, either. So that’s where getting it just right, getting there is a good thing to do. Another thing, Database Health Monitor catches. I didn’t realize we’re going to plug Database Health Monitors so much along here, but is unclustered tables. And usually, there’s very rarely a case that you want to have an unclustered table or a table that doesn’t have a clustered index on it. So that’s usually where I start looking at as well as different missing index reports and things like that. And the final deadly sin we’re going to talk about today is blindly trusting third party tools or older smart maintenance scripts. Okay, my favorite one on this is SQL server maintenance plans and the maintenance plan wizard, where it will allow you to go in and rebuild all of your indexes. If you click the right combinations of settings, it’ll let you it’ll build a script that will rebuild everything and then reorganize everything, and then update all the statistics. Now, if you’ve just rebuilt all of your indexes. You’ve already got the most up to date statistics. They don’t need to be rebuilt, and there’s no reason to reorganize it after doing that. So one of my Peeves over time is using SQL server maintenance plans to be able to set up indexing jobs. They’re almost always going to do it wrong, trust me, just stay away from them. That’s another check in Database Health Monitor that if somebody’s using SQL server maintenance plans, not using agent jobs, but maintenance plans to do re indexing, we usually catch it and report on it, because there’s usually something going really wrong.
Mitchell Glasscock 29:57
In the case, I’d say another honorable mention, and this is in the. Realm of index maintenance, but also adding indexes blindly trusting database tuning advisor, because that’s a great way to over index your tables.
Steve Stedman 30:11
Yeah, my gosh, when I originally built the outline for this DTA or the database tuning advisor, was supposed to be in here, but somehow it fell out of my agenda. Okay, good one. Yeah, database tuning advisor, I don’t even know where to start with how bad it is.
Mitchell Glasscock 30:24
I mean, I think we harp on it every couple episodes too, yeah.
Steve Stedman 30:29
And I think one of my favorite things I say about it is that if you were Microsoft selling SQL server and you wanted to figure out a way for people to have to buy more licenses, more processors spend more money on your system. You’d build something like database tuning advisor that actually makes you think you’re improving it, but ends up adding a bunch of just complete rubbish indexes that bloat out your system. Okay? So, yeah. So some better ways forward and some takeaways here. Yeah, maintenance isn’t really about fragmentation so much anymore. Really want to focus more on statistics and the actual performance impact on it, rather than just moving things around and reorganize them in the indexes. Was going to talk a little bit about database health, monitor indexing reports here, but we’ve already covered some of those along the way. There are a lot of indexing reports in there, everything from yeah statistics to missing indexes to unused indexes. Check it out. It’s worth looking at to understand your system a little bit better. Okay, so I think that then yeah, I guess that kind of wraps up the overall summary there. So really, the decision framework that I wanted to take a look at here is, does this index hurt queries? Are your statistics old? And if you think it’s hurting the queries, how can you prove that? And I think there’s a lot you can do with execution, thing plans and things like that. But before we get to our wrap up, hey listeners, if you’re loving these deep dives and mind blowing insights on the Stedman sequel podcast. Imagine getting even more exclusive episodes behind the scenes, bonus content and premium interviews you won’t hear anywhere else. Head over to our YouTube channel right now and hit that subscribe button turn on notifications so you never miss out on the content dropping every week. Join 1000s already unlocking the full experience, and don’t get left behind. Subscribe on YouTube today. Okay, so hopefully at this point, with our seven deadly sins, plus the three bonus ones, plus the don’t use DTA, one that Mitch threw in, good catch Mitch, hopefully all of these show how easy it is to do more harm than good with index and statistics maintenance, what we want to do is just shift away from those just blanket jobs and default settings to make sure you understand what the parameters are, what they’re doing, and basically evidence based fixes there. So I want to throw out the question to the listeners, which of these deadly sins and indexing that we’ve talked about here are you guilty of, or which of them don’t you agree with? That’d be an interesting topic. I’d love to have someone on the podcast to maybe talk about that. But please leave a comment on YouTube or wherever you’re watching this. I’d love to hear your war stories on dealing with indexes. So at this point, I just want to say, grab Database Health Monitor for real, real visibility in some of these there’s a free 30 day trial at databasehealth.com and check out Stedman solutions for more episodes, free tools and consulting. Our next episode, we’re actually going to cover some of the newer features in Database Health Monitor. I think Mitch, you and George are going to do that one. All right. Well, thanks for tuning in to the Stedman sequel podcast. Mitchell, thank you for joining me today. Thanks for having me. Keep your indexes lean and your statistics fresh. We’ll talk soon. Have a great day.
Steve Stedman 34:12
Thanks for watching our video. I’m Steve, and I hope you’ve enjoyed this. Please click the thumbs up if you liked it. And if you want more information, more videos like this, click the subscribe button and hit the bell icon so you can get notified of future videos that we create.