Podcast Discussion with Brent Ozar

1400We each have our way of going about things–this is what makes us unique.  When it comes to getting data out of the database, many times we might think that SQL Server would go about getting data the same way we would.  If you think about scanning a Microsoft Excel document, how would you find the record you are looking for?  How does that differ from SQL Server?

My guest for this episode is Brent Ozar and we chat about internals and how SQL Server processes your request and what you need to consider as SQL Server returns your result.

Transcription: Brent Ozar

Carlos L. Chacon: This is the “SQL Data Partners” podcast, and my name is Carlos L. Chacon, your host. For this episode, Brent Ozar has agreed to come and chat with us, compañeros, about some SQL Server internals.

We’re going to discuss some situations about how SQL server will handle our queries. We want to see if our thinking and SQL Server’s lines up. Brent, of course, is one of the most recognized names in the SQL Server space.

My objective today is to not embarrass myself in this conversation. Compañeros, you know I’m a knuckle-dragging Neanderthal, and I’m hoping Brent doesn’t pick up on that too much for today’s episode, but I’m sure it will be a very interesting conversation.

If you enjoy this episode, I invite you to leave a rating or a review on this podcast on iTunes or Stitcher. This will help others be able to find the program more easily so they can enjoy it as well. It is always great to have you, compañeros.

I hope you haven’t broken too many New Year’s resolutions just yet. If you have, I still love you anyway. Welcome to the show.

[pause]

Carlos: Brent. The man, the myth, the legend.

Brent Ozar: Howdy, sir. Mostly myth, yeah.

Carlos: [laughs] Welcome to the program.

Brent: Thanks, man. It’s good to be here. It’s very fun to be here.

Carlos: Yes, I do appreciate it. One of the courses that you have is entitled “How SQL Server Thinks,” and you go through this exercise of asking the participants to try and think about how they would process these queries. This exercise I thought was super helpful for myself, and how to go through that.

Brent: Oh, good.

Carlos: It was very thought provoking. I think sometimes we assume a little too much about our SQL Servers. Perhaps we’re a little narcissistic, and don’t realize all the other work that SQL Server has to be doing. One of the first elements I thought we could discuss was the size in which SQL Server works with.

Brent: One of my most favorite inspirational moments as a presenter was sitting in through a session by a Professor Edward Tufte, who tries to teach you how to teach things. One of the things he said is you’ve got to put something in people’s hands, something physical that relates to what you’re doing.I’m like, “How on earth am I going to do that with SQL Server? It’s just a bunch of numbers, bits and bytes. How does this all work?” I thought, “Well, OK. What’s the smallest unit of something that I could put in people’s hands?” It’s an 8K page. Most of what SQL Server does, does in these 8K pages. I went through Stack Overflow’s open source database.

They publish their database via Creative Commons, so any of us can use it for demos. I said, “All right, I’m going to take a simple table that people will understand — the list of users — and I’m going to put it into Excel so that it ends up looking like an 8K page.”

Then, during the course of this session, I take these pages and I say, “I want you to be the engine. I want you to think of yourselves as doing this work just the way that SQL Server does.”

It’s so funny to see people’s eyes open up and all of a sudden go, “Oh! There are rows on a page and the more columns that I add to each row, oh my gosh, that’s less rows I can fit on the page. If I want to go through and find specific rows, I don’t have a shortcut. I actually have to look at every page.”

It’s so much fun to see people start to fold these things together and instead of thinking of them as groups of rows, think of them as pages. Then, all of a sudden it opens this huge door for people. I see all of these lights start to open up in their eyes and go, “Oh, now I understand where things like logical reads come from,” for example.

It’s so fulfilling to see this switch flip all of a sudden, when people start to see these pages matter.

Carlos: Yeah, I think that was one of the big eye-openers for me was that, as we go, we — as you mentioned in Excel — might be able to say, “Oh, there’s that individual cell that I want.” But SQL Server doesn’t go through that process. It’s not a row. It’s not a column. It’s a page. It has to process all of those pages.

Brent: Without a nice, fancy non-clustered index to get you quickly to the rows that you want. Oh my gosh, I mean it’s scan city. You’re ripping through all of these pages like pages in a book. Really makes a world of difference having those printed pages.

Carlos: Let me issue a query. SQL Server reads everything from memory. We talked about those 8K pages. It has to be there in memory. If it’s not there in memory, we’ll go out to disk and say, “Hey, disk. Will you please pass me the pages?” Brings them up and then it can start to read those.I think there’s potentially still a bit of confusion around how SQL Server does that work, in that we equate the number of rows returned with the level of effort SQL Server has put in to give us those rows.

Brent: Yes! Yes.

Carlos: I had a peer recently say, “Well, I’m only trying to pull the top ten records. This query has been running for four minutes.” Right? [laughs]

Brent: Yes. When people have the physical pages in their hand, then they start to get it. I’m like, “You can’t give me the first five if you have an ORDER BY in there.” I got to go build the whole list. I got to sort the list. We’ve got to think about where we’re going to set aside all this space to work on the list. Is it going to be physical pages that you’re going to scribble somewhere?It’s fun as the presentation unfolds because you can see the developers say things like, “Well, I choose B-tree [mumbling] ,” and I can be like, “No, no! Hold up! As a human being, how are you going to accomplish this?” It starts to break down these barriers of, “Oh, I thought there was something magical happening inside the engine.”

But, no, no, no. It’s just pages. It’s just pages that SQL Server has to scribble down and find the answers to. It’s magical.

Carlos: Let’s say we have a table. The table has four columns. As you mentioned, it’s going to have just one clustered index. That’s what it has there. Just for some easy numbers — I’m not sure that it matters at this point — let’s say it has 1,000 pages.

Brent: Gotcha.

Carlos: If we pass this query, and it needs to read that…I guess we’ll just start from the basic, SELECT *. As we mentioned, SQL Server’s going to grab that and it’s going to start reading those individual pages.

Brent: Pages in order. Yeah! It’s so neat to think about how not only is it going to rip through those 1,000 pages, but unless you tell it like an ORDER BY, you don’t know which index it’s going to use, if there’s multiples. It could use any one that satisfies your query. You don’t know whether those pages are going to be in disk or on memory, and it doesn’t really matter.People used to think, “Oh, I got to tune so that I read less stuff from disk.” Just read less pages, regardless of where they’re at. All of a sudden, your query is going to start performing better. I always want to have this giant asterisk over my head when I say that. There are edge case scenarios where reading less pages will actually make the query perform worse.

But I try to give people general advice in the start of this, that as long as you follow basic rules and go from reading 1,000 pages down to just one or two pages, all of a sudden this thing really starts to perform. There’s less locking and blocking going on, too.

Say that you needed a lock on those 1,000 pages while you’re getting your work done, due to there’s an update involved in a query or something like that. If I can get you to touch less pages, it’s going to clear out this table for concurrency. Suddenly hundreds of users can hammer at it exactly the same time and improve performance. Makes a huge difference.

Carlos: You mentioned sorting. Let’s talk a little bit about that. Before we have that sort, we’re just reading those pages. It doesn’t matter how many columns we chose. We have one clustered index. We’re reading all the 1,000 pages no matter what we do. Now we have a sort. Now we’ve modified what SQL Server has to do. We’ve involved another database in the process, right?

Brent: The classic example of this is the white pages in the phone book. Say this is the thing that was sitting up on your grandfather’s fridge. Nobody uses these anymore, but it was the white pages ordered by last name and first name. What if I told you, “Go get me everybody in the city ordered by first name.” First, you’re going to have to read through the who entire phone book.Then, you’re going to be scribbling people down as you go, because none of us are smart enough to remember all the thousands or millions of people that are in the phone book. So we are going to be writing them all down, sorting them by first name. SQL Server doesn’t cache any of that. It goes through and scribbles it all every time, either in memory or in TempDB, SQL Server’s working staging area.

It’s going to do this whole sorting thing, give you your answers, and then throw that work away. It’s never going to reuse it. If you do the same query five times in a row or a hundred people are doing it simultaneously, all this work happens for every single session.

It’s so amazing to pull the hood off of that one too and say to people, “I want you to go build this entire query yourself using just pens and paper, and sort all this data. Now I want you to go do it again and again.” I used to think as I was a developer, “Well, it’s in cache. SQL Server just did this, so I should be able to just query it again and get it.” If we’re doing any kind of sorting, whammo!

We’re going to redo all of that CPU work every single time. People often say, “Well, I don’t have an ORDER BY in my query. But I am joining a couple of tables together.” Ouch! Guess what? You’re going to be sorting those in order to join them together. We end up having this implicit ORDER BY even when we don’t have ORDER BY in the query.

SQL Server only caches those raw data pages, not the joined-together pages from multiple tables or any of our SORT BY outputs. Crazy! Often when I’m dealing with developers, they’ll say, “Well, I could build a better database than that.” That’s how open source gets started.

You can go through and look at MySQL, Postgres. There’s a lot of tools out there. There are better databases, quote unquote. I’m going to use that term really loosely — “better databases” — where they have those kinds of options, but a lot of this is, you’ve got to put it together yourself. There’s advanced switches and knobs you have to throw.

I find that even in a database like SQL Server, where it has a lot of really good defaults, there’s a lot of things in there that just work magically by default without having to throw switches. We don’t even know the switches that we need to flip inside SQL Server, let alone when you start jumping into open source, and there’s all kinds of switches that you have to flip.

Carlos: It takes a lot more know-how.

Brent: Savvy. Yeah.

Carlos: That’s right, savvy, to do that.

Brent: I think, to some extent, developers are qualified to do it. You see a lot of the Facebooks, the Twitters, the big huge sites, where there’s teams of developers that run their own databases internally or use open source databases and they know it really well. They’re able to wring a lot of performance out of it.Because they’re developers, they will pop open the source code of the database and go, “Oh! I see why this works this way. It will make me a better developer.” We don’t get that luxury in SQL Server. The closest we can come to popping the hood and reading source code is to go to training sessions. Go to SQL Saturdays, read books. That makes you a much better developer, just knowing how the internals work.

Carlos: There you go. Talking about those switches. For some reason, that scene from “Apollo 13” where they’re in space. He’s put that little post-it note. This switch is the one that he needs to flip.

Brent: [laughs] Yes.

Carlos: Getting those just right. You get the wrong one, and who knows where you’ll be, right?

Brent: Yes. It’s dangerous. There’s so many switches around there that we can just go and flip. They cause performance to go horribly awry. Priority boost sounds fantastic. Turns out, it’s not.

Carlos: Even some of the trace flags that are available, they get thrown around like, “Oh! You can use it for this one specific very purpose,” and then all the system gets affected by it, and you’re like, “Well, that’s not exactly what I was hoping.”

Brent: How did this work?Usually I’ll tell people, whenever you’re going to throw a switch, tell me why you shouldn’t. Give me the explanation of what will break when you throw this switch. If they go, “Oh, nothing. It’s just going to work.” All right, then you don’t know the switch well enough to flip it yet. You have to go research and find out ways where this breaks things before you’re qualified to go turn that switch on.

I use that rule for myself. I don’t want to sound like I know everything. Whenever I see something that looks like a really good fix, I’m like, “All right, well it’s probably too good to be true. Let me go find out what’s really going on inside this thing.”

Carlos: I was presenting at the .NET Group here in Richmond, VA. We were doing a little T-SQL review. We started talking about sorting, how painful this can be for SQL Server. I tossed out the suggestion that instead of sorting in SQL Server, that they consider trying to sort some of those things in the application. Easier to scale, all those kinds of things. I thought they were going to run me out of the building. Like…[laughter]

Carlos: We need this data! We need it sorted in our application. Anyway, we started talking a little bit about sliding windows. They were like, “We don’t need all million records. I only want the first hundred,” blah blah blah. Then we got into windowing functions. Interestingly enough, I did some quick testing. I guess I should say, I have seen queries improve by rewriting them using a windowing function.

Brent: Sure!

Carlos: Well let me just take a peek at what that sorting would do using a Windows function. I had two queries. The first one was SELECT Name, and I had an ORDER BY. The second one was using a Windows function to do basically the same thing. The weird thing was, my sort operation, the cost, was actually the same for both queries. I thought, “Hmm. That’s kind of strange.”Then it dawned on me. In the first select with ORDER BY, I was only using a single column. I changed that to a SELECT * ORDER BY.

Brent: Boom!

Carlos: Then, boom![laughter]

Carlos: That cost went through the roof. I thought, “Oh, OK.” I guess the windowing function had forced me to be very specific in what I was bringing back, whereas [inaudible 14:41] we just start with, “OK, let me see what’s in there,” and we start building our queries with SELECT *, things like that. Thinking about what we need to bring back is also important.

Brent: Oh, man. I have this session, “Watch Brent Tune Queries.” You can see the whole thing if you go to brentozar.com/go/tunequeries. It’s an hour, hour and a half long. I think the recorded version’s from Sweden or something. One of the things that I say is, when someone brings me a query that’s not performing well, there’s two things that I do just as soon as they hand it to me.The first thing that I’ll do is comment out the ORDER BY. The second thing I’ll do is, out of everything they have in the select statement, I’ll take all of it out and just return the number one. Select one from, and then whatever the tables are. Just with those two changes, I’ll look and see what the difference is before and after.

If all of a sudden we’re across the finish line, whatever it is they wanted in terms of speed, I’m not going to hand this back to him and say, “We’re done.”

What I’m going to say is, “All right. First off, tell me, are you sure you need it ordered in the database?” Because now, all of a sudden, you’ve seen the difference here. And, “Do you need every one of those fields?” Or just, “Tell me the exact ones that you can’t live without, the stuff that’s really important.”

You’d be surprised how often all of a sudden, people are like, “Oh, wow! I can’t believe it was that different. All right, let me go back to the drawing board and think a little bit about what I exactly need out of the database.” You nailed it when you say, often people think, “Screw the database! I need this stuff out of the database.”

When I explain to people, “All right, enterprise edition. US $7,000 per core, standard edition US $2,000 per core,” I can’t scale that up easily. It’s really expensive to throw CPU power at it. That’s what sorting is, essentially, is all CPU.

But as a DBA, I’ll fight for you to get more application servers and more powerful application servers instead of being stuck on these crappy two vCPU VMs with two gigs of RAM. I’ll go to bat and make sure that you get the nice beefy application servers that you want. Then we can both be happy together, because we’ll spend less on licensing.

Then I can turn around and give you nice big awesome application server boxes. Then all of a sudden, they realize that we’re in the same fight together, and everybody wins. They’re like, “Oh, OK. It turns out this database stuff isn’t so bad.”

Carlos: To that point, knowing what we want, or what we need in our queries, we may only be looking at two columns, but if we tell SQL Server we want all the columns, SQL Server’s going to think, “Oh, you need all the columns,” and it’s going to go do that work to make sure that it gives that to you well, as efficient as it can. If you only need those two columns, only ask for those two.

Brent: Yeah, I used to concentrate as a DBA, I’m like, “Oh, don’t return back fields you don’t need, because it will take a long time to say those fields over the network.” That’s just the least of our problems, compared to sorting them, building that list, and writing them all down in order. The more columns that you add, the more space that it takes, the longer the sorts take.The examples that I use in “How to Think Like the Engine,” I want to say it’s a 50x cost increase by just doing an ORDER BY whenever I’ve got the SELECT * on this particular table. 50x slower queries — man, that blows! Just picking the fields that you want, suddenly it drops down to like 45x instead of 50. Drops down to 5x, but yeah.

Carlos: Now that we have the queries that we want, we can then start thinking about indexes potentially, right?

Brent: Yeah.

Carlos: Scaling that even further, because we’ve narrowed down here’s what we need, we could potentially presort some of that in our index. Then we’re off to the races.

Brent: Yeah, I want to give my developers a prebaked copy of whatever it is that they want. I want it prebaked, presorted in the database already so that when they ask for it, SQL Server’s only looking at a few pages. It’s able to render those results very quickly. Prebaked for databases doesn’t mean I need to persist the whole data set permanently and refresh it every half hour or anything like that.Indexes are just a lightweight copy of the table. Of course, they’re as lightweight as you design them. You can make ugly indexes if you want, as well. But I like to think of it back in the phone book thing again. When you want to find all the dry cleaners in the phone book, you really don’t want to have to go through the white pages looking at every single one of them, seeing if it has dry cleaners in the name.

This is when you come up with the yellow pages in the phone book where it’s organized by business type. You seek directly to the dry cleaners, and you are out of there. I can give my developers lots of indexes that match up with exactly the way that they’re going to query the table.

Of course, the more indexes that you add, every time someone enters or leaves your city, that’s additional work that you are going to have to deal with in maintaining your indexes. I like to tell people, aim for five or less indexes per table with five or less fields per index. Nothing magical about those numbers. It’s just that I have two hands, each with five fingers on them.

It tends to make them move pretty easily, and people will remember those numbers. You can certainly go beyond five indexes at Stack Overflow. We’ve got some tables that are 30, 40, 50 indexes on them, but it’s because the database servers has boatloads of RAM, they are all solid state drives underneath, the developers take querying very seriously.

The more you know about the rules, the more you can push the boundaries of those rules, but for starters, just aim for five or less indexes per table, five or less fields per index.

Carlos: Maybe before, I was a little more hesitant because it’s going to take more write space and whatnot. Then there’s the care and feeding. But now I guess I lean a little bit more towards, if I can identify a good need for it or there is this query that, “Hey, we need this to run much faster,” then I’m all for creating that index, but I also know that I have good care and feeding mechanisms for my indexes.It’s not just create it and forget about it. I use all those scripts and whatnot, because I am looking at that. Then I am going to take a peek at that logging to see, “OK, how many times are we rebuilding these indexes and things? Do I need to make a change based on this care and feeding?” That’s why I lean that way, but it’s because I’m making an effort into watching those indexes.

Brent: It also makes a difference if the application’s constantly changing, if my developers are constantly adding, removing or changing queries. We build a screen in the app that we think everybody is going to use and it turns out nobody uses it. You have to go back and look to see how often is the index actually getting used by queries, because over time, some or parts of your app are no longer interesting to people.So it’s a matter of shedding those indexes that weren’t as important, and then building new ones that match better closely to your today’s usage patterns of the application. I am all for adding indexes, because it’s a lot safer in most cases than changing code. Who wants to change code?

You have to go through testing, QA, deployments, all that. If I can give you a couple, few indexes and all of a sudden the users are happy, everybody wins. That’s a total good thing. In a perfect world, would I like everybody to handcraft every query? Sure, but nobody has time for that. We all want to ship products so that we can go out and get paid. That’s really what’s it’s all about at the end of the day.

Carlos: In order to use those indexes to the best of our ability, you talk something about sargable. So if your index be sargable, and I am not sure that we’ll have a ton of time to get into that, but you have a blog post that we will put it in the show notes for today that will point people to what makes basically good filter criteria. I guess there are one or two that we should talk about.

Brent: I like to think of it in terms of the white pages of the phone book again. If I say, “Go find me all the people whose last name starts with Smith,” you’re going to jump straight to the Smith section, you are going to read it until the names no longer matches Smith, and then you are out of there.If I say, “Tell me everybody whose uppercased last name is like Smith, you and I would think, we still jump to the Smiths, read them out and keep going. SQL Server is not like that. There’s this whole problem with collations. Some collations will work, some collations will not. SQL Server has to do this lowest common denominator thing, build an execution plan that’s going to work for every collation.

It will say, “All right, I’m going to uppercase every single last name in the database and then check to see if it matches Smith.” Even if my database isn’t the case sensitive collation, SQL server is going to go through all of that work. What’s worse is, remember it only caches raw data pages, not output. It’s going to go through and uppercase everybody’s last name every single time you run the query.

That’s a hardcore extreme example, whole upper thing. Most of us don’t uppercase the query results anymore. We say, “Go find something that matches this,” but anything with LTRIM or RTRIM often functions on dates. Any kinds of cast or convert, you’re rolling the dice there as to whether or not SQL Server is going to run it every single time.

That means whenever you have a search argument that’s like that…whenever you’re saying, for example, where uppercase of last name or where the RTRIM, LTRIM of last name equals something, that means to SQL Server, “Well, I can’t efficiently use an index with these search arguments. These search arguments won’t let me use an index effectively,” so this is where this term sargable comes in.

SARG is “Search Arguments.” S-A-R-G. It’s one of those made up of consultant-y words like “performant” or “compressive,” but it basically means that we can write better queries if we know what’s sargable and what isn’t. That’s where that blog post comes in. It’s one of those things where as soon as you see this in action once, all of a sudden you go, “Oh! I never need to learn this lesson again.”

This explains something very simple on SQL Server. Now, don’t use the month function or the year function on dates if you are trying to search for things, for example, or in your joins. Then all of a sudden again, performance goes through the roof, just with that one simple tip.

Carlos: Let’s transition to what I call the “SQL family portion” of the program.

Brent: Oh my goodness![laughter]

Carlos: Here we get to hear a little bit more about you and some of your experiences and…

Brent: Oh boy.

Carlos: One of the questions I like to ask people is what their favorite SQL tool is.

Brent: Aside from the stuff that I write, obviously, because I’m going to put that aside, I use that every day. That’s cool. I’m not going to pimp my stuff here. The number one thing that’s helped me for more than a decade is Adam Machanic’s sp_whoisactive.I’m sure that a bunch of people say this every time that they come in, because it’s an awesomely powerful tool, but it’s one of those things that it blows me away isn’t included inside SQL Server, because it’s just so simple. Everyone needs to know what is going on on the SQL Server right now.

If you use that tool and know just a couple of commands, get_locks is an interesting parameter, get_plans, get_task_info. You don’t have to know all of the parameters by any means, but just those will help you get an amazing start — get_plans, get_locks, get_task_info. You can start to really get a feel for what’s going on inside your database.

Carlos: Yes, that’s a very cool tool. Adam was nice enough to be on the show earlier and talked a little bit about that. Actually, my takeaway from that conversation was getting involved a little bit quicker if you are in the development process. Taking a look at that at some of the lower stages so you get a baseline.Right? Who would have thought of what it is that you’re expecting so that you can feel more confident with the query as you move forward.

Brent: You know, I have one of the most duct tape ways of using it that I’ll show developers. I’m like, “All right, when you think it’s slow, run it five times in a row. Don’t even digest. Just hit F5 five times in a row and look to see what’s happening.”If it’s the same queries that are frozen up continuously, or even they’re just showing up all the time, it’s time to go look to see what those queries are doing and why they are called so often. Before you run a profiler trace, just bang F5 a few times on sp_whoisactive, and see what keeps showing up.

So often, I’ve had developers say, “Oh, I didn’t know that query ran so often. Where’s that coming from?” And all of a sudden they find an N+1 bug or something.

Carlos: You’ve been around the block, right? Many different scenarios have a very successful consulting practice now…

Brent: Oh, thanks.

Carlos: In putting that all together, what’s one of the best pieces of career advice that you received along the way?

Brent: Oh, man. When I was in high school and I went applying for colleges, somehow along the way I ended up applying to MIT, mostly for laughs.I wanted to see what the process was like. I went in for an interview. The way that they did interviews at the time is, you would go to a local graduate of MIT and interview with them. So, I go to this company that made bowling balls and I’m interviewing with one of their staff.

As we talk, near the end of the interview he said, “Do you see yourself going to MIT?” I was like, “Heck no! I am not the kind of a person who goes to MIT.”

“You know, I’m not that…” And he’s like, “Tell me more about what you mean.” Over the next course of discussion, we figured out it’s all human beings. These are just people who are normal human beings. He walked me through a list of celebrities.

He’s like, “You understand that these people all started with nothing. The only thing that got them to where they are is their drive and belief that they can go do something and accomplish something.” None of that sunk in at the time. I was like, “OK, whatever.” I did not go to MIT, needless to say, I dropped out of college.

It was years later when it came a time to go start a company. It was very weird because I never wanted to start a company. I like a salary. I like stability. I like a paycheck, to check out at a certain time and walk away and know what’s going to happen.

When I finally came time to start a company, it was a weird thought that well all right, “I’m a human being, and human beings start companies. No one is more qualified than I am to do this so, let’s give it a shot.” It’s been that looking at other people and remembering that they are just human beings who started from nothing and just ran with it, has been really weirdly empowering.

Whatever it is that you want to go do, go look at other human beings who’ve done it. Look at what their track has been, how they got along the way. They faced setbacks. They had tough times. They’re just human beings who have to buckle down and keep sucking it up and working at it. They don’t have any magical skills that you don’t have.

Carlos: Our last question for today. Brent, if you could have one superhero power, what would it be, and why would you want it?

Brent: I would really like to be able to see the future, just because there is all this uncertainty, especially when you go start a business. You know how it is when you’re…I’m like, “I have no idea what’s going to happen six months from now, a year from now, two years from now.” Sure, it’s nice to say, “Well, you can go make it anything you want to.” But life has these weird setbacks and changes.I would love to be able to know, what’s it going to be like 10 years from now? What’s it going to be like 20 years from now? It would be nice to look in the future and go, “All right, at the age of 60, I’m going to be able to be retired and I’m still going to have all my health and senses,” or “I’m going to be in a car accident at 55, so it’s time to stop, just continuously go to the beach.”

[laughter]

Carlos: Smell the roses a little bit.

Brent: Yes, that would be phenomenal. I’d really like to see that. I’m not as worried about failure or anything like that. It’s just…I want to know how much time I have left to make as much of a difference as I can.

Carlos: Very interesting. Brent, thanks again.

Brent: My pleasure! Good to be here.

Carlos: As always, compañeros, if there is something you want to hear about or you have some other question, you can reach out to me on Twitter. I am @CarlosLChacon. Or you can shoot me an email at [email protected]. We will of course have the links to the show notes today for some of the podcasts, and of course, Brent’s training class up on today’s show notes at sqldatapartners.com/podcast.Compañeros, I will see you on the SQL trail.