What does it take to move AI agents from demos to reliable production systems? In this episode, Hamza Tahir explores how MLOps principles are shaping the future of generative AI, covering workflows, agent harnesses, fleets, and the infrastructure needed to build durable, scalable systems. The conversation dives into open source tools, production challenges, and how ZenML's new project, Kitaru, helps developers build resilient, replayable, and observable agent systems.
1201. In this bonus discussion from January, we look at why Canada has been without a current homegrown dictionary for twenty years and how John Chew is leading the charge to fix it. We look at how John got the job and the unique challenges of funding a dictionary in a bilingual country. John also shares how his aphantasia — the inability to visualize imagery — actually makes him a better data organizer for the complex world of lexicography.
OpenClaw is currently one of the biggest buzzwords in tech. It’s a digital agent software that runs on your computer and taps into a large language model (LLM) to operate autonomously.
In agentic AI, the intelligence of the latest AI models joins forces with the reality of your computer hardware. The models can — with your permission — read your emails, access your calendar, create and edit files on your computer, create and automate programs, browse the internet, send text messages, and more… much more. With Raspberry Pi’s extensible hardware, they can even access peripherals via the GPIO pins to receive inputs and perform actions. This is where AI meets our digital lives, our automated homes, and the industrial edge.
Agentic AI doesn’t merely answer questions like a web-based generative pre-trained transformer (GPT). It’s capable of operating with a degree of autonomy — making decisions and completing multistep tasks. Agents utilise a wide array of tools and adapt to results, typically with a minimal amount of human intervention.
Raspberry Pi provides an isolated environment, giving you full control over the operating system and hardware stack; this makes it the ideal platform for running agentic AI models in a contained space
Instead of giving an agent a specific prompt or writing any programs, you can give it a general instruction and it will wander off with your hardware and software to find a solution. Here are some examples:
“You control a Philips Hue lighting system on my network. Turn the lights on at sunset and off at midnight.”
“You monitor my soil sensor on Pin 21 and control a relay on Pin 22. Every hour, read the moisture level and activate the pump for three seconds.”
“You monitor my Raspberry Pi AI Camera. When an object classified as a parcel appears, capture a still image and send it to me via Telegram.”
“Every 10 minutes, scan my network and compare discovered MAC addresses against a file called known_devices.json. If an unknown MAC address is found, look it up via the MAC Vendor API to identify the manufacturer and send me an email.”
“Take a screenshot of my screen every 30 minutes and look for tasks, to-dos, URLs, or work in progress. Send me a report at the end of the day outlining what I worked on.”
Sounds terrifying. Or terrific. Or a mixture of both. With the right setup, an AI agent adds serious chops to your workspace, giving you access to a powerful new way of working and controlling the world around you.
With the wrong setup, this kind of autonomy has the power to do considerable harm. It opens up your computer to new threats via prompt injection, and inadequate vetting of tasks can cause damage and unintended behaviour. Take this story about a computer science student who asked OpenClaw to join Moltbook and other platforms — unbeknownst to the student, the agent then set up a dating profile for him and started screening his potential matches.
While this sort of behaviour can be humorous, a financial misstep or an errant email to your boss would be far less amusing. That’s why Raspberry Pi is the absolute ideal platform for this kind of new frontier of computing. Rather than running OpenClaw on your main computer where it can access your reminders, your mail, and the web browser containing your passwords, put OpenClaw in a secure Raspberry Pi environment where you control the entire stack and operating system.
All of this is in beta, so make sure to keep an eye on it. With that in mind, let’s get started…
Check out issue 166 of Raspberry Pi Official Magazine for the full tutorial
You can find the rest of this article in issue 166 of Raspberry Pi Official Magazine, which is available online. You can also subscribe to the print version of our magazine. Not only do we deliver worldwide, but those who sign up to the six- or twelve-month print subscription will receive a FREE Raspberry Pi Pico 2 W!
You can find Raspberry Pi Official Magazine on Facebook, X, Threads, LinkedIn, and Mastodon. You can also contact the team via email: magazine@raspberrypi.com
It’s here. Starting today, SharePoint Copilot Apps are in public preview – and they change what Copilot can do for your users. Instead of describing a task in a back-and-forth chat, users can approve an expense, triage an incident, or run an onboarding checklist as a real, interactive app, right inside the Copilot canvas – not a wall of text.
Here’s the power: you can surface almost any interactive UX component directly in the canvas – filterable data grids, multi-step forms, interactive maps, live charts and KPI dashboards, schedulers, or a purpose-built approval panel. All fully interactive, built with the web stack your team already knows, and no new platform or hosting to stand up. If you can build it on the web, you can bring it into Copilot.
This is the next wave of Copilot: not only better answers, but helping people move from intent to outcome – natural-language reasoning on one side, real guided experiences and business actions on the other.
Announcement
Today we’re excited to announce the public preview of SharePoint Copilot Apps, shipping as part of the SharePoint Framework (SPFx) 1.24 preview. It’s a new way to bring guided, action-oriented experiences into Microsoft 365 Copilot – so users can review, validate, decide, and complete work without leaving the Copilot flow.
The split is simple: Copilot helps users express intent and reason over context; SharePoint Copilot Apps provide the UX, permissions, validation, and dependable operations that actually get the work done. And you build them with the industry-standard web stack, MCP Apps, and the proven SPFx packaging model – hosted automatically in Microsoft 365 tenant, with no extra infrastructure to stand up or run.
Why this matters
Many enterprise workflows can’t end with a generated response. Approvals, updates, submissions, and line-of-business actions need structure, accountability, and predictable execution. SharePoint Copilot Apps connect the flexibility of natural language with the reliability of governed business operations.
This opens up new opportunities to:
Turn user intent into real business outcomes, not just generated responses.
Combine Copilot reasoning with dependable operations – approvals, updates, submissions, validations, and workflow actions.
Increase user confidence by showing the right data, choices, constraints, and consequences before action is taken.
Reduce context switching by bringing the operational experience into Copilot instead of sending users out to separate tools and portals.
Just bring your component
Here’s the part developers will love: you focus on one thing – your UX component. The platform does the rest. Microsoft 365 handles hosting, tool routing, security, and governance automatically. There’s nothing to wire together, nothing to operate. Install SPFx 1.24 and your first app can be running in your tenant this afternoon.
Because it’s built on open web standards – not a proprietary runtime – your AI coding agent already knows how to build these. Tools like GitHub Copilot, Claude, and Codex can scaffold, generate, refactor, and debug these components right in your IDE, in the JavaScript stack your team already uses.
Write once, reach everywhere
The same UX component isn’t tied to one surface. Build it once and expose it across Microsoft 365 – in Copilot, in SharePoint, and in Microsoft Teams – reusing a single component everywhere your people already work. Existing SPFx investments carry forward instead of being rebuilt, so you maximize what you’ve already shipped.
What You Can Build
SharePoint Copilot Apps shine when users need to complete an outcome, not just get an answer: review data, make a decision, validate inputs, and trigger a trusted action. Each solution can render multiple inline experiences and multiple full-screen experiences, surfaced based on user intent.
Examples include approvals, operational dashboards, incident response, onboarding assistants, CRM task panes, project reviews, field operations, workday hubs, procurement requests, support triage, finance updates, and partner-built industry solutions.
Here’s one in action – a My Day scenario that gives users a personal plan and relevant context, powered by Work IQ.
See It in Action: My Day solution
The demo should make the customer value obvious: Copilot understands intent, the app provides structure, and the user completes the outcome without leaving the Copilot experience.
Built for Enterprise Developers and Partners
SharePoint Copilot Apps are built on SPFx and the modern web stack – JavaScript, TypeScript, React (or Angular, Vue, Svelte – your choice), MCP Apps, and the familiar tools you already use. Create one package with the proven SPFx model and deploy it within your Microsoft 365 tenant, reused across Copilot, SharePoint, and Teams – no rebuilding the core interaction pattern, no custom hosting to operate.
And this isn’t an unproven foundation: the SPFx ecosystem already serves tens of millions of end users every day. This preview extends that install base straight onto the Copilot canvas.
Open to developers everywhere
During public preview, any developer, in any Microsoft 365 tenant, anywhere in the world, can build SharePoint Copilot Apps – no Microsoft 365 Copilot license required. That’s the lowest possible barrier to entry, by design: customers, partners, MVPs, and ISVs across every region can start today. (Licensing is subject to change before general availability.)
Public preview: considerations and availability
A few things to know as you get started:
Build today. The Copilot Workbench and full developer experience are available to everyone starting today – you can build and test SharePoint Copilot Apps right now.
Worldwide rollout in progress. End-user availability is rolling out globally and will be fully functional worldwide by July 20, 2026. If some capabilities aren’t visible in your tenant yet, they’re on the way.
Preview software. This is a public preview – capabilities, APIs, and the “SharePoint Copilot Apps” working name may change before general availability. Build accordingly, and tell us what you find.
Getting Started
Install the SPFx 1.24 preview – available now from npm
We’re eager to hear from developers, partners, MVPs, enterprise teams, and ISVs building real-world scenarios. Try the preview, share what works, and help shape what comes next. Please send input and feedback via the SharePoint Framework issue list, and join our weekly community calls and follow us on LinkedIn and X for the latest Microsoft 365 platform announcements.
GitHub repository for samples – we’ll start with 4 scenario samples with sample data (including sppkg file for easy demo) – contributions welcome
Closing
SharePoint Copilot Apps are a major step toward making Copilot a place where people move from intent to trusted outcome. Built on SPFx, powered by modern web technologies, and hosted in Microsoft 365, this preview gives customers, partners, and developers everywhere a practical path to bring real business operations into the Copilot canvas.
Move users from intent to outcome. Install the SPFx 1.24 preview. Build your first SharePoint Copilot App today.
We can’t wait to see what you build.
Note: “SharePoint Copilot Apps” is a working name for public preview and may change before general availability.
Postman achieved the AWS AI Competency in Agentic AI Tools, and that says as much about your APIs as it does about ours.
I’ve spent a lot of time this year talking with enterprise customers and partners about AI. What strikes me is how consistent the pattern is.
The model isn’t the hard part. The challenge is everything that comes after the prompt.
Organizations can already reach powerful foundation models from multiple providers. The trouble starts when those models need to interact with real systems, business processes, and production data. In June 2025, Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Gartner’s analysts note that many of these projects are early-stage experiments driven by hype and aimed at problems the technology isn’t suited to solve. They also estimate that of the thousands of vendors claiming agentic AI capabilities, only around 130 represent genuinely agentic products.
The model selection problem is largely solved. The infrastructure problem is not.
Getting APIs ready for how agents actually discover, understand, test, and call them reliably at scale is where most AI initiatives hit friction. Add governance, compliance, and regulatory requirements for enterprises in regulated industries, and the challenge compounds.
That’s why I’m glad to share that Postman has achieved the AWS AI Competency in the Agentic AI Tools category.
What the AWS AI Competency actually validates
Learn why AI-ready APIs matter for agentic AI and how Postman’s AWS AI Competency helps enterprises move AI systems into production.
The AWS AI Competency isn’t a self-certification. AWS introduced the Agentic AI Tools category to recognize platforms and development tools that help teams build, deploy, and manage agentic AI systems while meeting enterprise requirements for governance, security, and compliance. Partners go through technical validation and have to demonstrate successful customer implementations against AWS’s standards for security, reliability, and operational excellence.
The Agentic AI Tools designation covers platforms that support the full development lifecycle, from design and specification through testing, governance, and production operations, across different regulatory environments.
This isn’t recognition for a demo environment. It reflects the capabilities enterprises need to move AI from experimentation to production and to build the engineering discipline required to operate AI systems at scale.
AI agents run on APIs, and API quality determines agent reliability
The question most enterprises are asking today isn’t whether to use AI. It’s whether their infrastructure is ready for it.
AI agents depend on APIs to reach systems, retrieve information, run workflows, and take action. But there’s a specificity problem that doesn’t exist in human-driven API consumption: a developer can infer intent from ambiguous documentation and adapt. An agent can’t. If an OpenAPI specification omits authentication scopes, misrepresents response schemas, or fails to document error codes and rate-limit behavior, the agent fails. Silently or loudly, but it fails.
As agents become a distinct buyer class that discovers services, evaluates options, and completes transactions on its own, the quality, discoverability, and governance of an organization’s APIs will directly determine whether that organization can take part in an agent-driven economy. An API that a human developer can work through with effort isn’t necessarily an API that an agent can call reliably at scale.
Even the most advanced models can’t compensate for unreliable API foundations.
Postman sits at this layer of the agentic AI stack. By helping teams design well-specified APIs, enforce design consistency through Postman API Governance rules powered by Spectral, and validate API behavior with automated test suites before an agent ever calls an endpoint, Postman lets organizations build AI systems on a foundation they can trust.
And for teams that want to build agents themselves, the Postman AI Agent Builder lets them turn any existing collection into a production-ready MCP server. Existing API documentation, request examples, and tests become the foundation for agent integration. The APIs a team has already built and documented in Postman become tools an agent can discover and call, without a separate integration layer.
Building agent-ready APIs at scale: the PayPal example
We’re already seeing this shift across our customer base.
PayPal shows what happens when an organization treats its APIs as strategic infrastructure built to be consumed by both human developers and AI agents.
Since publishing their public Postman workspace, PayPal’s collections have accumulated more than 100,000 forks, which puts them among the most-forked on the Postman Public API Network. The business impact is concrete: time to first API call dropped from 60 minutes to 1 minute, and testing cycles that used to take hours now finish in minutes. Engineers on the Postman Enterprise plan save roughly one hour per week on API development workflows. The collections are structured, versioned, and machine-readable by design, which is exactly what makes them usable by AI agents as well as human developers.
That agent-readiness is now operational. PayPal published its MCP server as a Postman Collection, presented at POST/CON 2025, giving developers a ready-to-use, fully documented set of API requests that cover payments, invoices, disputes, shipment tracking, subscriptions, and more. The collection uses Postman’s built-in OAuth support, which reduces the authentication friction that typically slows agent integration. The result: an AI agent can discover, authenticate, and call PayPal’s commerce APIs using the same collection infrastructure that human developers already rely on.
Mark Lummus, Head of Product, Developer Tools at PayPal, explains the principle behind it:
“Postman has become a front door to PayPal, and increasingly the developer walking through it is an AI agent. We built our collections and Flows so humans and agents read them the same way, turning discovery into a first API call in under a minute and, over three years, more than 100,000 forks. The AWS AI Competency reflects the platform discipline behind making PayPal agent-ready by default.”
Bringing agentic AI to AWS builders
As part of our growing collaboration with AWS, Postman is helping teams build, test, and govern AI-powered applications directly within the tools they already use.
Postman MCP server in Kiro
Kiro is AWS’s spec-driven agentic IDE, built on the Code OSS platform and designed around structured, intentional development rather than open-ended code generation. When a developer describes requirements in Kiro, it produces three structured artifacts before writing a line of code: requirements.md (user stories and acceptance criteria), design.md (technical architecture), and tasks.md (an implementation checklist). This spec-first workflow gives AI agents and tools exactly the kind of structured context they need to operate reliably.
Kiro includes native MCP support, so it can connect to any MCP-compatible tool server. Through the Postman MCP server, developers can reach Postman workspaces, collections, environments, and tests from inside Kiro without context-switching. Teams can search private APIs in their organization’s catalog, generate client code from existing OpenAPI specifications, run test suites, and keep collections synchronized with their codebase, all within the environment where the code is being written.
Postman Agent Mode on Amazon Bedrock
Postman Agent Mode, our AI assistant, is powered by Anthropic’s Claude models through Amazon Bedrock.
For enterprises, the infrastructure choice matters. Amazon Bedrock offers two inference profiles to match different compliance requirements: In-Region keeps requests within a single AWS region for strict data residency compliance, and Geo Cross-Region routes within a geography (US, EU, and others) for higher throughput while respecting regional boundaries. This architecture lets enterprises use AI-powered developer tooling while keeping the compliance, security, and data residency controls their regulated environments require.
In practice, Agent Mode helps developers generate test suites from existing collection structure, troubleshoot failing requests using workspace context, and keep Postman Collections synchronized with Git repositories as APIs evolve.
API Catalog integration with Amazon API Gateway
The Postman API Catalog integrates with Amazon API Gateway to close the gap between governance and day-to-day API development, and the integration works in both directions.
Teams can import OpenAPI 3.0 and 3.1 specifications (in YAML or JSON) from API Gateway directly into the Postman API Catalog, where they appear alongside associated environment metadata and auto-generated collections. They can view deployment status and CloudWatch metrics within the Postman context. And they can export API specifications back to API Gateway, or deploy HTTP API schemas directly from Postman to a specific API Gateway stage, which creates a continuous loop between design, testing, and deployment rather than a one-way handoff.
The API Catalog is available to Postman Enterprise customers as part of large-scale API governance programs.
Moving AI from pilot to production
The Postman MCP server is available in Kiro today. Agent Mode on Amazon Bedrock is live. The API Catalog integration with Amazon API Gateway is available now.
For AWS customers, systems integrators, and technology partners building enterprise AI solutions, this milestone is about more than a competency badge.
Gartner’s 40% cancellation prediction isn’t a verdict on AI itself. It’s a warning about the gap between experimentation and production-readiness. The APIs, governance, testing, and operational foundations underneath AI systems are what decide whether those systems perform reliably at scale. Getting that infrastructure right is not a model problem. It’s an engineering problem.
As organizations move from AI experimentation to enterprise-scale deployment, preparing APIs for agents will become just as important as selecting the model itself. For many enterprises, it will prove to be the harder challenge.
That’s exactly where Postman is helping teams succeed.
Erik Darling here with Darling Data and today’s video we are going to carry on in our task which is learning how to better align our queries and our indexes. If you need help aligning your queries and your indexes, boy do I have options for you. You can hire me for, aside from watching these videos, you can hire me for consulting, do this stuff all day.
You can also purchase my training. The videos that you’re watching here are just tiny little snippets from the full course material in the Learn T-SQL with Erik course. The link to buy that for a hundred bucks off is down in the video description if you feel like doing that sort of thing and watching more videos of me. It’s crazy. You can also become a supporting member of the channel, ask me office hours questions, and I guess outside of the downstairs links you can also do other things that would make me think of you as a more useful human being.
Such as liking this video, subscribing to this channel, and forcing all of your friends. Hijack their browsers and force them to love me as well. If you need SQL Server performance monitoring, I got you covered.
There’s nothing Erik Darling won’t do for you. Maybe a couple of things. But this thing I’ll do for you. I would do anything for you but I won’t do that.
Anyway, I don’t like that song. Totally free, open source. You can see everything it’s doing. It’s free. It’s right out there on GitHub. It’s a bunch of T-SQL collectors.
They all run on a schedule. They collect important performance information from your SQL Server, put it into pretty charts and graphs, and allow you to talk via your robot companions using MCP servers to do that analysis on your performance data. The MCP stuff is all opt-in.
It is not on by default if you don’t want it broadcasting that it’s there. But it’s just, you know, gives you a different way of… figuring out what’s up with your SQL Server aside from just looking at the pretty charts and graphs and doing your own form of analysis.
So, all that good stuff. If you want to see me live out in the world and you happen to be in the Croatian area, I also got you covered. June 12th and 13th.
I will be at Data Saturday Croatia. I have an advanced T-SQL pre-con. It’ll be the material that you’re seeing here and more. If you come to the class, you get all of the T-SQL stuff. All of the T-SQL videos that I publish as part of the full course.
So you show up, you hang out with me for a day, and then you get like 100 hours of videos to go watch at home. But until then, let’s continue our maddening descent into heat brain leaking hell. I guess that’s what this is.
Maybe it’s just allergies. I get those too. The databases are just allergic as hell to everything. Especially users and developers. Just like me.
Anyway. We’re going to look at some interesting sort of tipping point queries. And this video is going to explore both rewriting queries to get better performance and tweaking an index to get better performance. So you get a twofer on this one.
Don’t say I never did nothing for you aside from all this stuff I already do for you. Anyway. We’re going to start by running this query. And we are going to use drop clean buffers.
Not because this one ends up terribly. Because the next one will end up terribly. So we’re just like this worst case scenario. This has a little go to after it.
So it executes twice. Even if you look in the messages tab, you will see this handy little message here. Beginning execution loop. Batch execution completed two times. Thank you. But the first query, it is a little bit slower. It does take about 1.2 seconds to run. And the second query takes about half that time.
And this is just the effective cache data. Right? And what’s kind of funny is it’s like when you look at these things, it’s like almost hard to spot where they really go astray. Like sure, this takes 60 milliseconds.
This takes 237 milliseconds. Somehow we end up at 922 milliseconds in the nested loops join. So the nested loops join did spend some extra time in there. I’ll talk about why in a minute.
But if you look down here, really the big difference in time. It’s not this, right? That’s about like 12 seconds different. That’s actually 60 milliseconds slower somehow, right? 237 to 295.
But this is at 460 milliseconds. Now part of that is because the nested loops join is responsible for a little bit more work than it lets on if you are just looking at the graphical execution plan. If you right click and you go into the properties, you will see this prefetch attribute assigned to your nested loops join.
This one just happens to be unordered. The same thing would happen if it were ordered. But this is just essentially telling SQL Server to go out and read a bunch of data ahead of time and get some extra stuff that we might need to make this query run and return stuff.
So the nested loops join here doing a little bit more work than in this one. We’ll forgive it though. But this isn’t really like the crappy one.
The crappy one comes. So this is looking through 2013-03-18. This is looking through 2013-03-19. And if we run this one, this is where things get demonstrably worse, right?
Because we have hit a tipping point when SQL Server is no longer willing to give us the query plan that we had before. It is no longer willing to do that key lookup. It just goes ahead and scans the clustered index.
Scanning the clustered index on the POST table for me takes about 8 seconds when I’m reading from disk. When I’m not reading from disk, it takes about 10 seconds. When I’m not reading from disk, it takes about 618 milliseconds.
I know which one I prefer. I also know that I’m pretty sure that I would prefer if SQL Server chose that lookup plan a little bit more reliably. How can we do that?
Great question. If we wanted to influence the optimizer to avoid the clustered index, we might rewrite the query like this, right? So what we’ll say is, again, sort of almost doing the same sort of self-join technique.
But we can just use an answer. We’ll say, just give me the top 1000 rows that would qualify for our original query. And just say where the ID from the outer POST table is in this list of IDs.
And this will influence SQL Server to use that same fast query. Use our nonclustered index instead of the clustered index, right? We’re going to go seek right into that bad boy over here.
Find the rows that we care about. And narrow it down to just the 1000 that we need to satisfy our query. And then go get the columns from the POST table via the self-join here.
And we return all that out. And that’s even a bit faster than either of the ones that we did before at 147 milliseconds. Now, IN and EXISTS often behave as far as the execution plan goes identically.
Often, right? But not in this case. When you have a top 1000 in an IN subquery, you look at this.
Again, the query plan, it looks like this. You see a top operator in it, right? SQL Server is like, oh, I need to limit this to a top 1000. If you do that with EXISTS, though, and I’m just going to get the estimated plan here.
Because if I run this query, things will not go as maybe they look here. The top 1000 is not, there is no top operator present in this. SQL Server will go and find all of the top 1000.
The rows and figure out which ones exist. The top is just ignored inside of EXISTS. SQL Server just throws that away.
It’s not valid to use top in there. So this does not turn out probably as you might expect or as you might have planned on it turning out. This would run for a long time and return a lot of rows.
Because we’re just essentially asking for everything from the POST table where the IDs exist. Even the top 1000 here and all of the rows that this would match. So we could do this, right?
But even this won’t turn out so great. What we’ll do is, no, I’m in the right place. There we go. We’ll say, we’ll put the top 1000 on the outer part of the query where SQL Server can no longer just dispose of it and throw it away and say, you’re not valid.
But if we run this, it’s still a little bit clunky, right? We’re back up to like a second on this. We had this tuned nicely with that in sub query.
If we’re not in a place where SQL Server might use, I should probably stop here for a moment. We get a batch mode adaptive join for this query, right? So good for us, right?
We’re on developer edition. So we’re getting that enterprise edition class for free. That’s cool. But we get a batch mode adaptive join here. SQL Server has chosen batch mode for the query.
And it said, well, I’m going to figure out. The best join strategy based on, at runtime, how many rows come out of one thing or the other. And then I will choose the correct join type based on how many rows leave here.
Great. You may not always get that. If you don’t always get that, you will most likely end up with a hash join here. And the hash join takes, on its own, just about the same amount of time.
Most of the stuff in here does still run in batch mode on rowstore. So you’re still getting just about the same improvement. Just without the join choice at runtime.
The join choice at runtime doesn’t add anything bad here. But it doesn’t add anything good here either. Batch mode makes this thing, like, still okay, but not where it was before. We did a much better job.
We could also force a nested loops join here if we wanted. And we could get down to an okay amount of time. But still 678 milliseconds.
That’s not really what we had before. If you recall. It was several queries ago with our beautiful in clause query with the top 1000 in it. This all ran in 135 milliseconds.
So that’s really more the time to beat. Everything is 600, 800 milliseconds. That’s a regression. It’s not a huge one. But, you know, it’s not really one.
We don’t tune queries to make them regress, do we? We tune queries to make them faster. It’s a crazy concept, I know.
Now, one thing that I want to point out is kind of funny about the array. The original query is… And all of the other ones are ordered by elements. Yeah.
Mouthful of marbles. Are creation date and then score descending. If we just run this query ordered by creation date and score, no longer descending on the score column, our original query still runs really quickly.
Actually, it runs faster than ever. Interesting. Well, we spent a lot of time rewriting this query to sort of have it suit the index that we had available better. But sometimes, every once in a while, you might be able to change an index.
And if we change our index definition, or rather we’re going to create a new index, I guess, to creation date and then score descending, so this fits the query that we were writing, better suits the query that we had originally, then we get the same fast execution as we did when we changed our query.
So, sometimes there are ways to rewrite your query to better suit the indexes that you have. Other times, if you have options and choices, you might choose to change your indexes up a little bit so that they better suit the queries that you have.
All right. I reached the end of the file. Thank you for watching. I hope you enjoyed yourselves. I hope you learned something. And I will see you next week on Tuesday for Office Hours.
All right. Have a great weekend, everybody.
Going Further
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
Log in
