Voice of the DBA

Author: way0utwest

  • Chill v Standard Mode in the Tesla

    This is part of a series that covers my experience with a Tesla Model Y.

    I bought the “slow” Tesla. The Model Y Long Range, which is fine. I wanted range more than performance. If you look at the 0-60 times, you can see a variety, but for 2021 this is how things rank.

    • 2021 Model S Plaid – 2.1s
    • 2021 Model S Long Range – 3.5s
    • 2019 Model 3 Performance – 3.1s
    • 2019 Model 3  Long Range – 4.1s
    • 2021 Model Y Performance – 3.6
    • 2021 Model y Long Range – 4.4
    • Model X – 3.3-5.5 s, depending on model

    What’s crazy is that I can “buy” a boost of acceleration for US$2000 that will drop me down around 4s. It’s a software upgrade.

    Is It Tempting?

    Getting into the Tesla and nailing the accelerator is exciting. The car really moves, and people that haven’t experienced it before are often surprised. I try to avoid it, usually playing the “video game” of how little power can I use, but it is fun once in awhile.

    When the weather changed, and I needed snow tires, I became more cautious. In fact, I accidentally had some slippage from pressing a little too quickly on the accelerator a few times. One of the things I changed for snow was setting the accelerator to “Chill” mode, which reduces how quickly the car reacts.

    Across the last few weeks, I’ve left Chill mode on for daily driving, even without snow. The car is still plenty fast, and I know I use less power. The other day I was curious how much of a difference it makes, so I turned it off in town. With a bright sunny day, no snow or moisture on the ground, I nailed the accelerator.

    It’s neck snapping quick. I can feel my neck muscles bunch up. In fact, I turned it right back off at the next traffic signal.

    A few days later I turned the Standard mode back on and drove for day. It’s fun, but I realized that most of the time I don’t really need that much acceleration. I tend to leave it off today most of the time, only turning it on if I want to have a little fun or I think I might need to be ready to accelerate quickly in traffic.

    That’s rare, so no, I’m not tempted by a $2000 upgrade for more speed.

  • The Usefulness of Database Features

    SQL Server is constantly growing and changing, as are most database platforms. There are lots of platform changes, among them enhancements to the T-SQL language. Microsoft has added window functions, in-memory structures, the ability to execute code in other languages, and more. Some of these features are well built and some need more work. What’s always interesting to me is what actually gets built and what doesn’t.

    There was an article recently on evaluating features in an RDBMS, and the article uses the JSON data type in Google’s Big Query as an example. The evaluation is interesting, examining whether the feature actually helps the user, or if it is mostly marketing. In this case, the feature is outside of the “normal” conventions of the platform,  but it is useful.

    When I look at SQL Server, there are features that I think are well implemented and others that aren’t. There are some that are very helpful, but some that don’t perform well, at least not at scale. There are also changes that people have requested, but Microsoft hasn’t decided to build (please upvote the numbers table).

    Many of us use a limited number of features inside the database platforms. We SELECT, INSERT, and UPDATE often, sometimes with the built-in functions, sometimes not. Many data professionals know what to use and avoid, but often developers may assume that any feature added will perform well. Most of them do very well with a few rows of data, but can be problematic at the scale of millions of rows. While we would want all features to work well at all scales, that isn’t something that’s going to happen.

    I accept that some features are there to help customers in different ways. I can’t imagine wanting to run Java code from a database call, but some organizations see value in this, so it’s a capability in SQL Server. I’m sure some people can’t fathom why I think a built-in numbers table is needed when there are easy ways to build one. I guess that’s why my priorities, yours, and Microsoft’s will differ, at least with regard to what things should change in the platform. What gets built is up to Microsoft.

    When you use a feature in any datastore, there may be tradeoffs with other techniques, and there may be problem domains where the feature works well or doesn’t. It’s important that you understand and learn the limits and advantages of any particular feature. It’s also important you know how to adopt a feature when it’s better or abandon one when it doesn’t meet your needs.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Daily Coping 25 Feb 2022

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

    Today’s tip is to look back at the pandemic, and find some pictures that are happy memories.

    A few of many:

    20210607_21453520210623_19384820210705_12485320210716_11521820210813_20144620210824_18315020210907_12260920211004_19191220211009_15204120211030_081814

  • T-SQL Tuesday #147 Wrap-Up

    I was the host this month for T-SQL Tuesday #147 and here is a look at the people who blogged (that I know about). If I’ve missed anyone, let me know.

    Rob Farley wrote about updates, not only with version upgrades, but also CUs and the need for automated testing.

    Deepthi Goguri talks about her first job and the requirement to move off SQL Server 2000. This was after her schooling was on SQL Server 2012. I like the emphasis on fear as a reason not to change, and the use of tools to find potential problems that could occur during the upgrade.

    Kevin Chant writes that he uses upgrade events as chances to improve the way a system works. He also uses the Data Migration Assistant to move, but do so carefully. Don’t jump across too many versions.

    Damien Jones asks us if we can avoid upgrades in the cloud. That’s an interesting perspective, and one I don’t see often. It is legitimate, as every time something changes, we need to test, and if there are issues, what do we do? Avoiding change is something that I find important in the short term but highly detrimental in the long term.

    Greg Moore writes about the challenges of convincing a client to upgrade.

    Glenn Berry gives us a way to make a case for upgrades, working against those that don’t want to change, and some thoughts on related tech changes that might help you decide to upgrade.

    Marcin Gminski talks about https://sqlwatch.io/blog/t-sql-tuesday-147-sql-server-upgrade-strategies/

    Alex Stuart notes that if it isn’t broken, why fix it? Don’t upgrade for no reason, but there are some reasons to upgrade and Alex lists them.

    Reitse Eskens gives us a basic process to follow when upgrading. These aren’t detailed steps, but these are the things I look at when upgrading.

    Gethyn Ellis talks about why we wait to upgrade and why we might rethink that.

    The first upgrade, from Todd Kleinhans, looks at the problems he had an how we got past an Access to SQL Server upgrade. I’ve been in this exact situation, back in the early 90s. It was a mess and very stressful, but I learned a few things. Including to avoid Access for years.

    Lastly, but not least, Martin Catherall provides some general thoughts on how he would approach an upgrade, with some tool suggestions to help.