The code review that made me count differently

When the query finally got faster, I was happy about the numbers. But the part that stayed with me was something else: I could see my younger self in the code I had just reviewed.

A small query, early in my career

When I was a junior developer, I needed to check whether two user records shared the same email address. In plain language, my question was: “Is there any record other than this user with this email?”

I translated that sentence almost word for word into MongoDB: match the email, exclude the current user’s ID, then count what remains.

MONGODB · MY FIRST APPROACH

// Is there another user with this exact email?
const otherUsers = await db.collection('users').countDocuments({
  email: 'person@example.com',
  _id: { $ne: currentUserId }
});
const duplicateFound = otherUsers >= 1;

The flow worked, and I sent it for review. Then a teammate asked why I needed the extra condition when I was already counting.

If the current user is already in that count, why not count everyone with the email? Two or more means there’s a duplicate.

That is the gist of the review, as I remember it. The simpler version was:

MONGODB · THE SIMPLER QUESTION

// The current user already has this email in the database.
const matchingUsers = await db.collection('users').countDocuments({
  email: 'person@example.com'
});
const duplicateFound = matchingUsers >= 2;

A small but important detail: after excluding the current user, one or more matches means a duplicate. Including the current user changes the threshold to two or more. The second version assumes the stored user already has the email being checked; for a new user or a change to a different email, that assumption does not hold.

The review hit me harder than the size of the change would suggest. I had written a query that followed my explanation, but I had not stepped back to ask whether the explanation itself could be simpler.

Years later, I recognized the pattern

Fast-forward to October 2026. At HCL GUVI, I was working on DORA, an internal CRM. This time the database was PostgreSQL, and the re-enquiry filter operated over about 2.69 million leads.

I asked an LLM to build the flow. It produced an implementation, but when I ran it, it was slow. Looking through the generated code, I found unnecessary work: fetching records and counting them when I only needed a count.

From a little distance, it felt familiar. Different database, different scale, but the same habit of turning a description directly into steps without questioning the work those steps created. I remembered that old code review.

Look at the data before counting it

Only around 2% of the leads had a re-enquiry date. The other 98% did not. That imbalance was the useful detail.

There were two questions to solve: how to retrieve leads that had a date, and how to count leads that did not. They were related, but they needed different changes.

First, index the small group

For the page query, I added a partial index containing only leads with a re-enquiry date. The index focused on the subset the filter needed.

POSTGRESQL · PARTIAL INDEX AND EXAMPLE PAGE QUERY

-- Only index leads that have a re-enquiry date.
CREATE INDEX leads_re_enquiry_date_present_idx
ON leads (re_enquiry_date)
WHERE re_enquiry_date IS NOT NULL;

-- Retrieve a page from that smaller subset.
SELECT id, re_enquiry_date
FROM leads
WHERE re_enquiry_date IS NOT NULL
ORDER BY re_enquiry_date
LIMIT 50;

That change brought the measured re-enquiry page query from 2,680 ms to 5.6 ms, about 480 times faster. It was a database-query improvement; it does not mean the entire page loaded in 5.6 ms.

Then, count what exists and subtract

The empty-date count was a different problem. Counting the rows without a date meant counting almost the whole table:

POSTGRESQL · COUNTING THE LARGE GROUP

-- The large group: roughly 98% of the table.
SELECT COUNT(*)
FROM leads
WHERE re_enquiry_date IS NULL;

Another part of the product already maintained a precomputed total. I did not need to calculate that total again. If I counted the small group with dates, I could subtract it from the total to get the group without dates.

POSTGRESQL · COUNTING THE SMALL GROUP

-- Count the smaller group, using the partial index.
SELECT COUNT(*) AS with_date
FROM leads
WHERE re_enquiry_date IS NOT NULL;

// Reuse the total already maintained by the product.
// Both counts must cover the same population of leads.
const withoutDate = precomputedTotal - withDate;

The arithmetic was simple: without a date = total leads − leads with a date. The useful change was deciding which group to count.

This depends on both counts describing the same population, including the same permissions, organisation scope, and applicable filters. The precomputed total also has to meet the feature’s freshness requirements. Subtracting a stale or differently scoped total would give a fast but wrong answer.

With that change, the measured empty-date count fell from 1,400–1,900 ms to about 79 ms.

These are recorded database-query timings from the project, not end-to-end page-load measurements or a controlled, repeated benchmark. I’ve documented the outcome and its scope in the DORA query-performance case study.

The part that made me smile

Seeing the improvement felt good. Remembering that teammate’s review felt even better.

Back then, someone helped me step outside the code I had just written. This time, I caught a similar pattern myself. It was a small, nostalgic moment: a reminder of how much my peers and seniors have shaped the way I think.

The MongoDB check and the PostgreSQL optimization are different techniques. What connects them is the question I had learned to ask: what do I already know, and how much work do I actually need to do?

One more lesson, for my next prompt

My first prompt should have included the data distribution and the fact that a total already existed. I gave the LLM the flow I wanted, but left out context that could change the solution.

Next time, I want to start with that context: what the data looks like, what is already available, and what result I actually need. And I still need to review the generated code and measure it.

That is how I arrived at this solution: an old review, a slow query, and a chance to use a lesson I had kept with me.