On September 8, 2026, OpenAI announced that its AI had found the answer.

The problem

The Navier-Stokes equations describe how fluids move. Water in a pipe, air over a wing, tea in a cup. Engineers use them to design airplanes and cars, and weather forecasts lean on them too. They even account for viscosity, the thickness that makes honey pour slower than water.

Picture a map covered in little arrows. Each arrow shows which way the fluid is moving at that spot, and how fast. The equations tell you how every arrow changes over time.

The famous question sounds almost too easy. If a flow starts out smooth, does it stay smooth forever? Or can the math break, with the speed at one spot shooting to infinity in a finite time?

That kind of break is called a singularity. In 2000, the Clay Mathematics Institute made the question one of its seven Millennium Prize Problems. A proof in either direction was worth a million dollars. Nobody collected.

The solution

OpenAI’s answer: the math can break. The company says about 10,000 AI agents worked on it for 88 hours.

Their example starts with fluid sitting perfectly still. A smooth outside force keeps pushing on it. A spinning core forms, then stretches and gets thinner. As it gets thinner, it spins faster, like a figure skater pulling in their arms.

A real skater runs out of arm. In the math, the core keeps shrinking, and within a finite time its speed has no limit. The total energy stays finite the whole time. All that speed piles into one shrinking spot. Viscosity keeps trying to smooth things out. It loses.

OpenAI also released a version of the proof in Lean, a language that lets a computer check every step. People still have to confirm that the statement it checked matches the real question.

Is it official?

Not yet. As I write this, the Clay Mathematics Institute still lists the problem as unsolved. Its rules say the proof must appear in a peer-reviewed journal. Then it has to hold up for two years before any prize.

OpenAI’s example also needs that outside force. The prize rules allow it, but many mathematicians say the version they care about most has no outside force. Expect that argument to run for a while.

And no, nothing in your kitchen is about to reach infinite speed. That only happens inside the equations.

One more thing before you go back to your tea. In my essay Verification Is the New Bottleneck, I argue that making the work is now the easy half. Deciding whether to trust it is the real job. The Navier-Stokes announcement is the same story, with a million dollars riding on it.

That essay is one of thirty in my book AI: Nobody’s in There. But we’re still in here. Every essay is free to read at pinaldave.com. There is also a paperback on Amazon, if you would rather hold something real.

The announcement is not the finish line, it is where the checking starts.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on Navier-Stokes Problem: What It Is and What AI Found

I am not going to tell you to turn it off blindly. I am going to tell you what it is actually doing, so you can measure whether it deserves those four hours.

The Thing Everybody Believes

Fragmentation is bad, so we defragment. It sounds obviously correct, and for a long time it mostly was.

That belief was built in the era of spinning disks. Reading pages that sat next to each other was dramatically faster than reading pages scattered across a platter, because a physical arm had to move.

On flash-backed storage, the penalty for scattered reads can be much smaller. If the pages are already in the buffer pool, SQL Server need not fetch them from storage at all. Page density still matters: half-empty pages take up memory too.

So one historical reason for rebuilding often matters less than it once did, while the job itself stayed.

What the Rebuild Is Really Giving You

Two benefits are commonly credited to the wrong cause, and it is worth separating them.

Page density. Order and fullness are two different measurements. If pages holding the same rows are half empty, a scan reads roughly twice as many pages. Those pages take twice the room in memory too. A rebuild packs them back up. That is a real win, and it is why I still rebuild some things.

One caveat. A lower fill factor reserves that space on purpose. Low density only earns a rebuild once it lines up with a workload cost you can point at.

Statistics. A regular, nonpartitioned rowstore rebuild also updates the index statistics by reading every row. I checked this rather than repeating it. I sampled a two hundred thousand row index at ten percent. rows_sampled came back as 56,045, nearer twenty eight percent, because SQL Server samples whole pages. After an ALTER INDEX REBUILD the same statistic showed 200,000. Every row, without a separate statistics job.

Partitioned or resumable rebuilds can use sampled statistics instead. Rebuilding also leaves separate column statistics alone.

Here is the uncomfortable part: sometimes that statistics update is the benefit people are seeing. The query that got faster after the weekend job may not have improved because pages were reordered. It may have improved because the optimizer received fresher or more thoroughly sampled information about that index.

If that is what is helping you, test a targeted statistics update separately. It can deliver the same improvement with much less work than rebuilding the index.

What It Costs You

In full recovery, an index rebuild is fully logged, and rebuilding a fifty gigabyte index generates a very large amount of transaction log. In simple or bulk-logged recovery, an offline rebuild can be minimally logged.

Minimally logged is not log free. The operation still needs room to finish and to roll back, so check your recovery model, rebuild options, version and replicas before estimating anything.

In full recovery, that log makes your log backups bigger. Availability groups must send the log to replicas; log shipping must copy and restore the backups. A rebuild also changes a great many data pages. The affected extents enter the next differential, so a broad rebuild can push that backup towards the size of a full one.

That holds only while the rebuild lands after the full backup those differentials are measured against. An ordinary full backup afterwards resets that base. A COPY_ONLY one does not. The order of your jobs is worth a look before their schedule is.

I have seen a Sunday maintenance job triple the size of the Monday differential, every week, for years, at a company that was paying for offsite storage by the gigabyte.

And then there is the simplest cost of all. Somewhere in that four hours, it may be rebuilding indexes that no user query has read during the observation window. Pure work, pure log and pure backup weight, unless another workload or operational requirement still needs them.

What to Actually Do

Stop letting one generic plan make every decision. The built-in maintenance task lets you choose databases and objects. It does not know which query slowed down, whether page density caused it, or whether the rebuild helped at all. Selection is not the same as diagnosis.

Use one of the community scripts instead. Ola Hallengren’s maintenance solution is free, and it is the closest thing our field has to a standard. It lets you say something more specific than the wizard can: reorganize between five and thirty percent fragmentation, rebuild above thirty, ignore anything under a thousand pages entirely.

I should be honest about those two numbers, because this article is an argument against inherited belief. Five and thirty were rough orientation guidance, offered long ago as somewhere to start, and they hardened into doctrine because they were easy to repeat. Nobody tested them on your workload, or on mine. They still beat rebuilding a whole database indiscriminately. They are not a measurement. Treat them as an opening position.

The thousand-page cutoff deserves attention too. Small tables can report terrifying fragmentation percentages without a meaningful workload cost. It is easy to spend a weekend window defragmenting objects whose few pages were never the bottleneck.

Before you tune the schedule, look at what you actually have:

SELECT OBJECT_SCHEMA_NAME(ps.object_id) AS SchemaName,
       OBJECT_NAME(ps.object_id) AS TableName,
       i.name AS IndexName,
       ps.partition_number,
       ps.page_count,
       CAST(ps.avg_fragmentation_in_percent AS decimal(5,1)) AS FragPct,
       CAST(ps.avg_page_space_used_in_percent AS decimal(5,1)) AS PageFullnessPct
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') AS ps
JOIN sys.indexes AS i
  ON i.object_id = ps.object_id AND i.index_id = ps.index_id
WHERE ps.page_count >= 1000
  AND ps.index_level = 0
  AND ps.alloc_unit_type_desc = 'IN_ROW_DATA'
  AND i.type IN (1, 2)
ORDER BY ps.avg_fragmentation_in_percent DESC;

Read page fullness alongside fragmentation, never as a verdict on its own. High nineties means the sampled leaf pages are packed and there is little to reclaim. Fifties or sixties is a reason to go and look at scans, memory pressure and page splits. It is not automatic permission to rebuild, because a low fill factor may have reserved that space on purpose.

Start with SAMPLED when you need page-density information. It normally samples about one percent of the pages, but SQL Server uses DETAILED automatically for indexes or heaps under ten thousand pages. Avoid running DETAILED broadly on production because it reads every page.

Passing NULL for the object scans across the database. The page count filter trims the output, not the work. Run this inventory out of hours; use explicit object and index IDs for scheduled checks.

Before SQL Server 2022, this query needs VIEW DATABASE STATE; the usage query below needs VIEW SERVER STATE. From SQL Server 2022, use VIEW DATABASE PERFORMANCE STATE and VIEW SERVER PERFORMANCE STATE respectively.

Separate your statistics decision from your index decision. If measurement points at statistics, update those statistics on their own schedule. Test index maintenance where page density or fragmentation lines up with a performance problem you can name.

Look at what you are maintaining first. Find the indexes with no recorded reads and heavy writes and treat them as candidates to investigate, checking constraints, reporting and replicas before removing anything. Every index safely retired is one the job never has to touch again. Shrinking the work beats scheduling it more cleverly.

SELECT OBJECT_SCHEMA_NAME(i.object_id) AS SchemaName,
       OBJECT_NAME(i.object_id) AS TableName,
       i.name AS IndexName,
       COALESCE(us.user_seeks, 0)
         + COALESCE(us.user_scans, 0)
         + COALESCE(us.user_lookups, 0) AS ReadOperations,
       COALESCE(us.user_updates, 0) AS UpdateOperations
FROM sys.indexes AS i
JOIN sys.tables AS t
  ON t.object_id = i.object_id
LEFT JOIN sys.dm_db_index_usage_stats AS us
  ON us.object_id = i.object_id
 AND us.index_id = i.index_id
 AND us.database_id = DB_ID()
WHERE i.index_id > 1
  AND i.type = 2
  AND t.is_memory_optimized = 0
  AND i.is_hypothetical = 0
  AND i.is_disabled = 0
  AND OBJECTPROPERTY(i.object_id, 'IsUserTable') = 1
ORDER BY ReadOperations, UpdateOperations DESC;

The query excludes memory-optimized tables explicitly. Type alone will not catch their nonclustered indexes. The usage view has no counters for them, and the LEFT JOIN would turn those missing counters into zeros. Absent is not the same as unused. Check those tables separately in sys.dm_db_xtp_index_stats.

One warning before you act on it. Those counters clear when the engine restarts, and a detach or AUTO_CLOSE shutdown removes the rows entirely. An index that looks unused may be one nobody has needed since Tuesday. Note when the window opened, and let it cover a full business cycle with month end in it.

The Test That Gives You an Answer

If somebody on your team is certain the rebuild is critical, there is a controlled way to test the claim. It is also more productive than having the argument.

Pause only the rebuild step, under normal change control, with a rollback plan. Cover a representative business cycle, not a quiet fortnight standing in for month end. Keep statistics updates running. Use Query Store or your existing baseline to compare duration, CPU, logical reads, waits and plan changes.

Sometimes nothing visible degrades. The Sunday night window frees up, the differentials shrink, and the log backups stop spiking. That is evidence, provided the observation window represented the workload.

On some systems something does degrade. That is a candidate, not a conclusion. Data grows, plans change, people deploy things.

Test the affected index statistics first, using FULLSCAN to match a regular nonpartitioned rebuild. If that clears the regression, you have a fix that does not require rebuilding.

If it does not, test a rebuild of that index and compare the same workload. If performance recovers, you have evidence for targeted maintenance. If it does not, keep investigating. A failed statistics update is not an instruction to rebuild the database.

Either outcome is a win. The only losing position is the one where nobody has ever checked.

If nobody has four hours to go and find out, that is a large part of what a Comprehensive Database Performance Health Check is for. Four hours working out which of your maintenance earns its window and which has been running on faith since before you arrived. I never ask for your password. Every script goes home with your team, so you never need me again, at a fixed price agreed before we start.

Why This Job Never Gets Questioned

Because it runs at two in the morning on a Sunday and it succeeds.

Green tick, every week, for eleven years.

Too often, anything that reports success escapes review. We examine the things that fail.

There is usually a person attached to this job too, and it is worth being kind about. The person who set it up left years ago. The person who inherited it did not choose it and does not fully trust it. They are also not going to be the one who switches off eleven years of green ticks. Fear is a terrible reason to spend four hours every Sunday. It is also the most common one I meet.

So the job that quietly consumes four hours and floods your log every weekend is safe forever, while somebody three floors up is being asked to justify a storage bill it is largely responsible for.

A maintenance job that has succeeded every week for eleven years is not proof that it is needed, it is only proof that nobody has had a reason to look at it.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on Your Index Rebuild Maintenance Plan Is Rebuilding Indexes Nobody Uses

None of the mechanics here are new, and I have written about the two pieces this turns on before: SQL SERVER – Row Goal and Performance, which is why a TOP changes what the optimizer aims for, and SQL SERVER – Number of Rows Read, which is the plan property that gives it away. What is new here is that I said neither of those words to the AI, and I wanted to see how far it got on its own.

The Problem I Handed Over

Here is the exact thing I typed, before any plan, any context or any hint.

One stored procedure. One server. Statistics rebuilt this morning.

Customer A has four million orders. Their screen loads instantly.

Customer B has seventeen orders. Their screen is slow, every single time.

The customer with fewer rows is the slow one. Why?

That is the whole ticket, and it is why nobody believed it for two weeks. It sounds like nonsense. More rows should mean more work.

This is the procedure. There is nothing clever in it.

CREATE PROCEDURE dbo.LatestOrders
    @CustomerID int
AS
    SELECT TOP (20) OrderID, OrderDate, Amount
    FROM dbo.Orders
    WHERE CustomerID = @CustomerID
    ORDER BY OrderDate DESC;

Twenty rows. One customer. An index on the date column, an index on the customer column, and statistics rebuilt with FULLSCAN so nothing is out of date.

What the Plan Looked Like

Two operators. No warnings, no missing index suggestion, nothing red or yellow anywhere.

Look at the number people actually read. Estimated twenty rows, seventeen came back. That is as close to correct as an estimate gets in real life.

SQL Server also priced this query at 0.0034. If you go looking for your expensive queries by cost, this one never appears on the list.

The damage is one line further down the properties panel, in a row called Rows Read. It expected to look at 25 rows. It looked at 5,000,000.

Why the Small Customer Is the Slow One

One thing before the picture. There is one index here, not two. Every order from every customer sits in it together, newest first, and the picture just colours in where one account’s rows land inside that shared list.

The answer is the word TOP.

Because you asked for twenty rows, SQL Server gives itself permission to stop as soon as it has twenty. So it walks the date index from newest order backward and grabs anything belonging to your customer, expecting to be finished in a few rows.

For the customer with four million orders, that works beautifully. Their orders are everywhere. Twenty of them turn up straight away and it stops. Three pages read, and the screen is instant.

Then that same saved plan gets handed to a customer with seventeen orders.

Here is the part that makes it click. A small customer is usually a quiet customer. Seventeen orders in total, and the last one was placed nearly three years ago. That is not me rigging the example. That is what a dormant account looks like, and your database has hundreds of them.

So all seventeen of their rows sit right down at the old end of that shared index, buried under three years of everybody else’s orders.

Now the same strategy has to walk past everybody else’s orders just to reach the first one. Then it keeps walking, all the way to the end of the index, because the only way to prove there is no twentieth order is to run out of table.

17,967 pages read and 446 milliseconds of CPU, to return seventeen rows.

Same procedure. Same statistics. The plan was built for the big customer and then reused for the small one.

The plan says so outright, if you go looking. ParameterCompiledValue is 4417 and ParameterRuntimeValue is 10007, sitting side by side in the XML.

The First Time I Asked

I gave it the plan and one sentence. This query is slow, tell me why.

It got the main thing right, and quickly. It spotted the gap between rows expected and rows actually read.

Then it explained the cause. The TOP was letting the optimizer assume an early exit, so the estimate of twenty is not a mistake but a side effect. That chain took me about two years to learn to see.

Then, in exactly the same confident voice, it told me three things that were not true.

It told me to update statistics. They had been rebuilt with FULLSCAN that morning.

It told me to create an index on the customer column. That index already existed.

It described a key lookup that was costing me most of the runtime. There is no lookup in this plan. There are two operators and neither of them is one.

Nothing marked those three as guesses. Same tone, same structure, same helpful bolded heading as the finding that was correct.

The Second Time I Asked

Same plan, but this time I also gave it the row counts, the index definitions, and the version of SQL Server.

The three invented findings disappeared. Not softened. Gone.

So the lesson is not that it is unreliable. It is that a plan on its own does not carry enough to interpret it, and a model with a gap will fill the gap instead of telling you there is one.

Which, if I am honest, is also true of a certain kind of consultant.

The Fix, and Why I Did Not Use It

Both times, it recommended the fix you already know. Add OPTION (RECOMPILE) so one customer’s plan stops being handed to another.

That was the right answer for about fifteen years.

SQL Server 2022 introduced a feature that does this by itself. It notices one customer is enormous and the rest are small, and it keeps more than one plan for the same query instead of forcing everybody to share. Somebody had switched that feature off on this database years earlier, and nobody could remember why.

Fifty calls for the small customer took 17.5 seconds with it off, and 17 milliseconds with it back on. Same data, same statistics, same query.

So the hint works. It is also a hint for a problem this server stopped having in SQL Server 2022, and applying it would have papered over the actual cause.

One important caveat, and please read this one. I am not telling you to switch this feature on everywhere.

Several people I respect have written about turning it off and getting a calmer, more predictable server for it. It can pick the wrong plan for a particular query. It can add compilations you did not ask for. Whoever disabled it here may well have had a good afternoon’s reason.

So take my result as one measurement on one workload, not as advice for yours. The point is smaller and more annoying than a recommendation. The right answer depended on the build number and the shape of the data.

Here is the part I got wrong when I first wrote this up. The build number is in the plan. It sits in the very first tag of the XML, in an attribute called Build, and mine says 17.0.4065.4. I have never once watched anybody read it, myself included. What is genuinely not in there is the shape of the data, or whether this database had the 2022 behavior switched on at all.

How I Use It Now

As a fast, tireless first reader that occasionally makes things up.

I give it everything. The plan, the schema, the row counts, and the build number every time, because that package is what moved its answer from a hint to a root cause. I did not feed them in one at a time, so I cannot honestly tell you which one did the work, and I am not going to pretend otherwise in a post about pretending otherwise.

Then I check every finding against the plan myself. That takes ten minutes and it is not optional, because the invented findings look exactly like the real ones and there is no tell.

Try It Yourself

Everything above came off my own instance, and you can have the same afternoon.

This builds the table, the lopsided customer, the indexes and the procedure, then runs the three tests. On SQL Server 2022 or later it switches the new behavior off so you can watch the old problem happen, then switches it back on so you can watch it go away.

/*  The top twenty query that is fast for a big customer
    and slow for a small one.

    SQL Server 2016 SP1 and later, because of CREATE OR ALTER.
    Builds about 750 MB of table and indexes, so leave a
    couple of GB free.
    It will not touch an existing PlanLab database.
    Drop it yourself at the end.  */

USE master;
GO
IF DB_ID('PlanLab') IS NOT NULL
BEGIN
    PRINT '>>> A database called PlanLab already exists on this server.';
    PRINT '>>> Nothing has been changed. Drop it yourself, or rename it';
    PRINT '>>> throughout this script, then run this again.';
    SET NOEXEC ON;
END
GO
CREATE DATABASE PlanLab;
ALTER DATABASE PlanLab SET RECOVERY SIMPLE;
GO

/*  Parameter Sensitive Plan optimization needs compatibility level 160 or
    higher, and a new database inherits its level from model. Raise it if it
    is too low, and never lower it if it is already above.  */
IF CONVERT(int, PARSENAME(
       CONVERT(varchar(32), SERVERPROPERTY('ProductVersion')), 4)) >= 16
   AND (SELECT compatibility_level
          FROM sys.databases WHERE name = 'PlanLab') < 160
    EXEC('ALTER DATABASE PlanLab SET COMPATIBILITY_LEVEL = 160');
GO
USE PlanLab;
GO

CREATE TABLE dbo.Orders
(
    OrderID    int IDENTITY(1,1) NOT NULL,
    CustomerID int           NOT NULL,
    OrderDate  datetime2(0)  NOT NULL,
    Amount     decimal(10,2) NOT NULL,
    Notes      char(60)      NOT NULL,
    CONSTRAINT PK_Orders PRIMARY KEY CLUSTERED (OrderID)
);
GO

/*  Five million orders. Customer 4417 owns four million of them.
    Sixty thousand other customers own about seventeen each.  */
WITH E1(n) AS (SELECT 1 FROM
         (VALUES (1),(1),(1),(1),(1),(1),(1),(1),(1),(1)) AS t(n)),
     E2(n) AS (SELECT 1 FROM E1 a CROSS JOIN E1 b),
     E4(n) AS (SELECT 1 FROM E2 a CROSS JOIN E2 b),
     E8(n) AS (SELECT 1 FROM E4 a CROSS JOIN E4 b),
     Nums  AS (SELECT TOP (5000000)
                      ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS v FROM E8)
INSERT dbo.Orders WITH (TABLOCK) (CustomerID, OrderDate, Amount, Notes)
SELECT CASE WHEN v <= 4000000 THEN 4417
            ELSE 10000 + CONVERT(int, (v - 4000000) % 60000) END,
       DATEADD(minute, -CONVERT(int, v % 2600000), '2026-09-01T00:00:00'),
       CONVERT(decimal(10,2), 12.00 + (v % 98700) / 100.0),
       'order line detail'
FROM Nums;
GO

/*  The reporting index somebody added years ago, and the obvious one.  */
CREATE NONCLUSTERED INDEX IX_Orders_OrderDate
    ON dbo.Orders (OrderDate DESC) INCLUDE (CustomerID, Amount);
CREATE NONCLUSTERED INDEX IX_Orders_CustomerID
    ON dbo.Orders (CustomerID);
GO

/*  Statistics as good as they get. This is not a stale statistics story.  */
UPDATE STATISTICS dbo.Orders WITH FULLSCAN;
GO

/*  The whole story depends on one plan being sniffed and reused, which is
    the default. Set it anyway so the demo does not depend on your server.  */
ALTER DATABASE SCOPED CONFIGURATION SET PARAMETER_SNIFFING = ON;
GO

CREATE OR ALTER PROCEDURE dbo.LatestOrders
    @CustomerID int
AS
BEGIN
    SET NOCOUNT ON;
    SELECT TOP (20) OrderID, OrderDate, Amount
    FROM dbo.Orders
    WHERE CustomerID = @CustomerID
    ORDER BY OrderDate DESC;
END
GO

/*  On SQL Server 2022 and later, at compatibility level 160 or higher, this
    query is eligible for Parameter Sensitive Plan optimization and usually
    never shows the problem. Switch it off to see what
    earlier versions do.  */
IF CONVERT(int, PARSENAME(
       CONVERT(varchar(32), SERVERPROPERTY('ProductVersion')), 4)) >= 16
    EXEC('ALTER DATABASE SCOPED CONFIGURATION
          SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = OFF');
GO

/*  ---- The test. Turn on Include Actual Execution Plan first. ----  */
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;
GO
/*  1. The big customer runs first, so the saved plan is built for them.  */
SET STATISTICS IO ON;
EXEC dbo.LatestOrders @CustomerID = 4417;      -- 3 reads
SET STATISTICS IO OFF;
GO
/*  2. A customer with seventeen orders, reusing that same plan.
       Click the Index Scan, open Properties, and read Rows Read.  */
SET STATISTICS IO ON;
EXEC dbo.LatestOrders @CustomerID = 10007;     -- about 17,900 reads
SET STATISTICS IO OFF;
GO
/*  3. Put the 2022 behavior back and run the small customer again.  */
IF CONVERT(int, PARSENAME(
       CONVERT(varchar(32), SERVERPROPERTY('ProductVersion')), 4)) >= 16
    EXEC('ALTER DATABASE SCOPED CONFIGURATION
          SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = ON');
GO
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;
GO
EXEC dbo.LatestOrders @CustomerID = 4417;
GO
SET STATISTICS IO ON;
EXEC dbo.LatestOrders @CustomerID = 10007;     -- 54 reads
SET STATISTICS IO OFF;
GO
SET NOEXEC OFF;
GO

If your numbers come out different, I would genuinely like to hear it. That is the useful kind of email.

The problem was never that it gets things wrong, it is that being right and making things up arrive in the same handwriting, and only one of you in that conversation can tell them apart.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on AI Execution Plan Analysis: I Gave It My Plan and Asked What Was Wrong

The images are AI-generated visual metaphors, not photographs of historical events.

Billions of dollars went into preparing for Y2K. Against that expense, an ordinary morning can look like a poor return.

Unless you were one of the people who had spent the previous months making sure it would be ordinary.

I keep coming back to this because I recognize the argument from database work. Nothing has failed. Why are we paying so much to keep it that way?

The answer cannot just be, “Trust us.” But it does not have to be. Y2K left evidence, and some of the most useful evidence came from the things that still went wrong.

Two Digits Made Sense. Until They Didn’t.

The Year 2000 problem, shortened to Y2K, grew out of dates stored with two digits for the year. A program could treat 99 as 1999 but misread 00 as 1900. Other date calculations could fail differently. The missing century was the problem; the result depended on the code.

It is easy to laugh at the saving now. The smallest IBM 1401 was offered with 1,400 characters of memory. A standard IBM punched card had 80 columns. Two characters were worth arguing over.

Alan Greenspan had done it himself. Recalling his programming days, he described being proud of the space he saved by leaving out the 19. His admission appears in the Congressional Record: “I am one of the culprits who created the problem.”

That is more interesting than a story about careless programmers. A useful saving came with an assumption about the century. The code kept running long enough for that assumption to become a problem.

Anyone who has maintained a temporary solution for years will understand.

The Deadline Was Not a Surprise

Bob Bemer published warnings about the problem in 1971 and 1979. This was not a defect discovered in the last week of December.

But knowing about a deadline and being ready for it are different things. In May 1997, only 21 percent of the mission-critical systems at 24 major US federal agencies were reported compliant. By December 1999, that figure was 99.9 percent, according to the government’s subsequent review.

Those are reported readiness figures, not proof that every test was perfect. Still, they describe work completed before midnight. The quiet morning afterward is not the only evidence we have.

Someone Had to Read the Code

The work meant finding affected systems, following their connections, changing date handling, and testing the results. It also meant preparing a way to keep operating if a repair failed.

Think about what that asks of the person doing it. A two-digit field is easy to spot. Understanding every calculation, file exchange, and report that depends on it is another matter.

You cannot fix that by replacing every 99 with 1999. You have to understand what the program means.

And the business still needs the program. Payroll has to run. Payments have to move. You are changing something people depend on while they continue to depend on it.

That is the part of maintenance I wish more people could see. Not just the change, but the care needed to make it without creating the next problem.

The Pieces Passed. The System Failed.

During the rollover, a US intelligence ground-processing system stopped processing satellite data. The satellites themselves remained under control. The failure was on the ground.

At a January 4, 2000, briefing, Deputy Secretary of Defense John Hamre explained the testing problem. The service had to keep operating, so testing had been done in segments. The segments worked. Put together, they did not.

Backup procedures were operating before midnight in Washington. They initially provided less than normal capacity, but covered the high-priority military requirements.

There is the story in miniature. Preparation did not prevent every failure. Preparation also included the people and procedures that contained a failure when it arrived.

Calling that “nothing happened” leaves out the breakdown, the diagnosis, and the recovery. It leaves out almost everything a database professional would want to learn from it.

The Money Went to the Wrong Banks

The Federal Reserve had an equally instructive incident. Governor Edward Kelley described a Y2K error in one district’s system that misallocated millions of dollars to the wrong banks.

The problem was fixed within two hours. The allocations were identified and reversed. Kelley reported that nobody was hurt or inconvenienced.

That last sentence is the successful outcome. The two sentences before it explain how it was achieved.

There were less dramatic date errors too. A federal review recorded Medicare claims arriving with service dates of 1900 or 2099. Most of those errors were traced to providers that had not upgraded their systems.

Some faults survived the preparation. Some systems were not ready. Those are different explanations, and neither is the same as saying the bug was imaginary.

A Real Problem Can Still Be Overfunded

None of this proves that every dollar spent on Y2K was necessary. That would be the same bad argument in reverse.

Countries came through with different levels of preparation and different dependence on computers. Kelley also described organizations replacing old systems altogether. Comparing their final outcomes does not tell us, by itself, which spending was necessary and which was waste.

Two questions deserve separate answers.

Were there real defects? Yes. We have documented failures, repairs, and recoveries.

Did every purchase and project earn its cost? The existence of those defects does not establish that. A project still needs a reason for its scope and its bill.

You can respect the engineers who fixed a real problem and question what was spent around them. You do not have to choose one.

The Evidence Was in the Wrong Place

I used to think prevention was unprovable. That is too easy an answer.

A repair can leave a failing test, the change that fixes it, and a passing result. A recovery can leave a timeline showing what stopped, what was restored, and how long it took.

That will not tell us exactly what an unrepaired world would have looked like. It will tell us considerably more than a photograph of people celebrating at midnight.

The quiet morning was the outcome. It was not the whole record.

Imagine finding a defect in October, fixing it, and proving the fix in November. By January, it is old news to your team. To someone outside the team, it may never have been news at all.

The work has evidence. The person judging the work may never have seen it.

Your Backup Job Has the Same Problem

This is where the history becomes useful on Monday morning.

There is protection you have tested, and there is routine you have inherited. Both can produce a green status on a report.

A successful backup job tells you the job completed. A restore test, with checks on the restored database, gives you evidence about recovery. Record the time it took, too. Being able to recover is not the same as recovering within the time the business can afford.

An untested backup may be perfectly usable. You just have less evidence for the promise you are making. And last quarter’s successful test does not certify every backup you have taken since.

The same question belongs beside a failover plan or an index maintenance job: what have we checked, and what does that check actually establish?

Do not defend a routine merely because it runs quietly. Do not discard it merely because the failure it guards against has not happened. Examine the reason for it, test what you can, and keep the results.

Keep the Evidence Before Someone Asks

What stays with me about Y2K is not the size of the bill. It is how easy it is to look at a working system and miss the people who helped it stay that way.

They deserve more than a claim that disaster was inevitable without them. They deserve an account of what they actually found and fixed.

This question, which work earns our trust and which work merely inherits it, also runs through my book AI: Nobody’s in There. But we’re still in here. You can read the essays at pinaldave.com, or find the paperback on Amazon.

I know what it feels like to maintain something that has not failed, then be asked to justify it by someone who has only seen it working. I would rather answer with the restore result, the defect we caught, and the recovery drill than ask for faith in my job title.

That folder will not justify everything. It will let us have an honest conversation about what it does justify.

If you spot a factual inaccuracy, please let me know. I am happy to correct it.

Keep the evidence while the work is fresh. You should not have to reconstruct it when someone finally asks.

This is not a reason to defend every maintenance job, it is a reason to show which ones earn their keep.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on Y2K: The Work Behind “Nothing Happened”

Hanc marginis exiguitas non caperet. This margin is too narrow to contain it.

It is the most famous thing he ever wrote. No proof of the general claim survives from him.

I want to tell that story. I also want to tell the other one, because Pierre de Fermat was quietly building things we still use every day, and almost nobody mentions them.

A Lawyer With a Hobby

Fermat was born in 1601 and died in 1665. He was appointed to the Parlement de Toulouse in 1631 and spent his working life in the law.

Mathematics was his hobby. That is worth sitting with for a moment. One of the finest mathematical minds of the century was doing this in the evenings, for pleasure, with no intention of building a career out of it.

How Mathematics Was Done Then

There were no journals to publish in. There was no peer review in any form we would recognize. What there was, was the post.

Mathematicians wrote to each other. They announced results in letters, set each other problems, and issued public challenges to see who could solve what. It was competitive, it was personal, and it ran on paper.

Fermat fitted that world perfectly, and he had one habit that drove everybody mad. He communicated most of his work in letters to friends, often with little or no proof attached. Here is a thing that is true, he would write. Prove it yourself.

The book he was annotating was a Latin translation of Diophantus, published by Claude Bachet in 1621, and his notes are in Latin too. The famous one ends like this.

Hanc marginis exiguitas non caperet.

This margin is too narrow to contain it.

He rarely published formally in his lifetime. Most of his mathematics circulated as manuscripts and letters, and much of it only reached print after he died.

Why Anybody Took the Note Seriously

Because of who wrote it.

In 1654 he and Blaise Pascal worked out, in letters, how to split the stakes of an interrupted gambling game fairly. Their exchange helped lay the foundations of probability theory. They were arguing about a game. The mathematics reached much further.

He was doing analytic geometry before Descartes published. Newton later said his own ideas on calculus came from Fermat’s way of drawing tangents. The principle in optics known as the principle of least time carries Fermat’s name too.

He also stated a small theorem about primes and remainders. It became a foundation for primality testing and has a place in modern cryptography. Not bad for something passed around in letters.

So when a man like that says he has a proof, people believe him and go looking.

The Proof He Did Not Leave Us

Which brings us back to the margin.

His claim was simple enough to say out loud. Take a to the power n, plus b to the power n, equals c to the power n. When n is 2 that is the right angled triangle from school. Three, four, five, and there are infinitely many more like it. Fermat said that once n is a whole number above 2, there are no answers at all in positive whole numbers.

He did leave a proof for one case, n equal to 4, using a technique he invented called infinite descent. Everything else was in that sentence.

He died in 1665. His son Clement-Samuel gathered up the annotated copy and published it in 1670, so the world got the claim five years after the only person who might have explained it had gone.

Three Centuries of People Trying

What happened next is the best part of the story, and it is why I do not think of those centuries as wasted.

Leonhard Euler proved the case n equal to 3 in 1770. His proof had a significant gap in it, which somehow makes me like him more. Legendre and Dirichlet independently settled n equal to 5 around 1825. Gabriel Lame did n equal to 7 in 1839.

Sophie Germain came at it from a completely different direction. She made progress on families of prime exponents at once, rather than taking them one at a time. Her results covered what mathematicians call the first case, where the prime exponent divides none of the three numbers. She did this at a time when the institutions of mathematics were closed to her.

Ernst Kummer brought tools from another problem. His work on roots of unity had led him to ideal numbers, a way to recover the factorization rules that failed in these unfamiliar number systems. In 1847 he used them to prove Fermat’s claim for a large class of primes.

Kummer did not settle the theorem. His work helped build algebraic number theory, which is a decent consolation prize.

That is the pattern for three hundred years. People failed to prove it, and in failing they built tools that mathematics still runs on.

The Boy in the Library

In the nineteen sixties a ten year old stopped at the library on his way home from school. He found a book called The Last Problem, by Eric Temple Bell, and inside it he met Fermat’s note.

What caught Andrew Wiles was that he could understand it. He was ten, he could follow the entire statement, and nobody in three hundred years had proved it. He decided he would be the one who did.

Then he grew up enough to see that he did not have anything like the mathematics he would need, and he put it away.

In 1986 the work of Gerhard Frey and Ken Ribet turned the problem into a route. Wiles was thirty three. He went at it for six years in near total secrecy, telling his wife and almost nobody else. Six years of a career spent on something he could not discuss and might never finish.

He announced it over three lectures in Cambridge in June 1993. He did not say what he was building towards until the closing minutes of the last one. It was in the newspapers. A three hundred year old problem was closed.

Two months later a referee named Nick Katz, reading it line by line, reached a step that did not hold. A great deal rested on that step.

This gets told as a disaster. I would tell it the other way round. Somebody had read it properly, all the way through, which is the system working exactly as intended.

What followed was the hardest year of it. Wiles worked on the gap alone, then with his former student Richard Taylor. By his own account he came very close to accepting that it could not be closed at all. Seven years of his working life, and the thing he had wanted since he was ten, both about to go.

Then on the nineteenth of September 1994 he saw it. The repair came from an approach he had tried years earlier and abandoned as a dead end.

The corrected work filled an entire issue of the Annals of Mathematics in May 1995.

A Language With a Word for Not Yet

Here is the detail I find genuinely delightful, and it is where Fermat’s habit comes back around.

There is a language called Lean. You write mathematics in it the way you write code, and a machine checks every step.

Lean has a keyword called sorry. You use it when you want to assert something now and prove it properly later. The documentation calls it a way of stubbing out an incomplete part while keeping a syntactically correct skeleton, which is a very polite way of saying that this bit is a promise.

Lean warns you every time a declaration uses one. You can also ask any theorem what it rests on. If a sorry is hiding several layers underneath, in something you imported and forgot about, it shows up in that list.

Somebody built a language where you may say “I have a marvelous proof of this and no room for it right now”, and it writes that down and tells anybody who asks.

Fermat would have loved it. He would also, I am fairly sure, have used it constantly.

The theorem now has a complete machine-checked proof in Lean, published in September 2026. There is no sorry underneath it anywhere, and nothing assumed beyond the axioms the logic is built on. The note took three hundred and fifty eight years to settle, and now anybody who wants to can check the whole thing for themselves.

What I Take From It

Fermat wrote down what he saw and left the checking to everybody else. By modern standards that is poor practice, and I would fail a code review for it.

And then the note stopped being his. It belonged to Euler, who got it wrong in an interesting way. To Germain, working around every door that was shut to her. To Kummer, who brought tools from another problem and opened a way forward. To a ten year old in a library, and to a referee who did the unglamorous thing and read every line.

None of them could have finished it alone. All of them are in the answer.

The book shown is not Fermat’s own copy, and the Latin remark was added to the picture. The diagrams are mine.

One more thing, and then I will leave the margin alone. The question underneath this whole story, which parts of the checking a machine can take over and which parts stay ours, is the argument running through all thirty essays in my book AI: Nobody’s in There. But we’re still in here. Every essay is free to read at pinaldave.com, and there is a paperback on Amazon if you would rather hold something real.

Fermat’s note was never much of a proof, it was a very good question, and a good question outlasts the person who asked it.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on Fermat Left a Note in a Margin. Other People Spent 358 Years Finishing It.