Count(column) vs Count(*)
#005 — September 24, 2025
Two weeks ago, I attended DjangoCon US 2025, and it was a very good experience. I met Justin Duke, the creator of Buttondown, which is the service that runs this newsletter. He asked me what talks I found interesting at the conference. I said Zags' keynote All The Ways To Use Django, because Zags mentioned that one of the strengths of Django is its modularity. You can use each of Django's components independently from one another. Justin shared that Buttondown uses Django extensively in the same way, leveraging each component independently for specific tasks.
I missed last week's issue. So, this week includes 2 weekly reports (Week 38 & Week 39). It also includes more fun facts about aggregation on the NULL data type, and blogs about evaluating database performance based on SQL statements.
Django Contributions Weekly - Y25 W37 - Sep 8 - 14
There were a total of 16 modified tickets last week, down from 52 from the last report for Week 34 (Aug 18 - 24). By the end of Week 37, 10 tickets were open, and 6 were closed.
Components
Number of modified tickets by component.
- Database layer (models, ORM): 4
- Documentation: 3
- Utilities: 2
- Generic views: 2
- Internationalization: 1
- Core (Cache system): 1
- contrib.auth: 1
- HTTP handling: 1
- contrib.admin: 1
End of Week Queues
Where the modified tickets landed by the end of the week.
- Unreviewed: 0
- Needs PR: 2
- Needs Review: 5
- Waiting On Author: 3
- Ready for checkin: 0
- Closed (fixed): 3
- Closed (other): 3
- Someday/Maybe: 0
Activities
Count of ticket activities last week.
- Reviewed: 2
- Assigned: 4
- Coded: 6
- Discussion: 24
Contributors
There were 18 contributors last week, a little down from 26 in the previous round. It's nice to see a few names from DjangoCon US attendees.
- Aaron (Weyaaron), 1
- Mike Edmunds (medmunds), 1
- Shubham Akhilesh Singh (shubhamsingh941889), 1
- Kevin Renskers (kevinrenskers), 1
- Samriddha Kumar Tripathi (Samriddha9619), 1
- Salman Mohammadi (Faravah), 1
- Adam Johnson (adamchainz), 1
- Lily Acorn (LilyAcorn), 1
- H. White (eevelweezel), 1
- Mridul (mriduldhall), 1
- Egor R (egor83), 1
- Clifford Gama (cliff688), 1
- Marcelo Elizeche Landó (melizeche), 1
- Tanishq (Tanishq1030), 2
- Mariusz Felisiak (felixxm), 4
- Tim Graham (timgraham), 2
- Simon Charette (charettes), 3
- Jacob Walls (jacobtylerwalls), 3
Django Contributions Weekly - Y25 W38 - Sep 15 - 21
There were a total of 56 modified tickets last week, back to normal after the conference. By the end of Week 38 week, 31 tickets were open, and 23 were closed, and 2 were marked as Someday/Maybe.
Components
Number of modified tickets by component.
- Database layer (models, ORM): 21
- Testing framework: 4
- Documentation: 4
- Core (Cache system): 4
- HTTP handling: 4
- contrib.auth: 3
- Migrations: 2
- Core (System checks): 2
- Core (Management commands): 2
- Utilities: 2
- Core (Other): 2
- Template system: 2
- GIS: 1
- contrib.staticfiles: 1
- contrib.postgres: 1
- contrib.admin: 1
End Of Week Queues
Where the modified tickets landed by the end of the week.
- Unreviewed: 2
- Needs PR: 4
- Needs Review: 10
- Waiting On Author: 9
- Ready for checkin: 2
- Closed (fixed): 16
- Closed (other): 7
- Someday/Maybe: 2
Activities
Count of activity changes to the ticket statuses last week.
- Assigned: 8
- Reviewed: 12
- Coded: 14
- Discussion: 60
Contributors
There were 22 contributors last week!
- Mridul (mriduldhall), 1
- Joel D Sleppy (jdsleppy), 1
- Clifford Gama (cliff688), 1
- H. White (eevelweezel), 1
- Simon Charette (charettes), 1
- Gangadhar Yadav (aryan7081), 1
- Carlton Gibson (carltongibson), 1
- Josh Thomas (joshuadavidthomas), 1
- loentwin (loentwin), 1
- Mariusz Felisiak (felixxm), 2
- Antoliny (Antoliny0919), 1
- Samriddha Kumar Tripathi (Samriddha9619), 2
- JaeHyuckSa (JaeHyuckSa), 2
- Shai Berger (shaib), 2
- Luna (blingblin-g), 2
- Tanishq (Tanishq1030), 2
- Simone Macri (simone-macri), 2
- Jason Hall (Jkhall81), 3
- Adam Johnson (adamchainz), 3
- Natalia Bidart (nessita), 5
- Sarah Boyce (sarahboyce), 13
- Jacob Walls (jacobtylerwalls), 16
count(column) vs count(*)
We've seen some interesting behaviors with the NULL value. Here is yet another one involving the count function. I'm running the following queries in duckdb, and it should run the same on Postgres.
Using a temporary table as an example, we see that calling count on the name column results in 3, even though there are 4 rows. The NULL value is not included in the count.
select count(name) from (values(null), ('Alice'), ('Bob'), ('c')) as t(name);
┌───────────────┐
│ count("name") │
│ int64 │
├───────────────┤
│ 3 │
└───────────────┘
On the other hand, the calling count with a star, count(*), results in 4, which is the total number of rows.
select count(*) from (values(null), ('Alice'), ('Bob'), ('c')) as t(name);
┌──────────────┐
│ count_star() │
│ int64 │
├──────────────┤
│ 4 │
└──────────────┘
If you play around with other aggregation functions, such as avg, you'll see they will also exclude NULL values in their aggregations. Be mindful of your dataset when writing your queries. You can use this knowledge to your advantage, or if you're not careful, you might end up calculating the wrong results.
In Brief
Django: avoid using .first() when retrieving a unique object - by Thomas Loiret
The author suggests using .get() instead of .first() to fetch a specific item, claiming that the ORDER BY clause injected when using .first() causes a slow down in performance.
Database-optimization-is-not-always-obvious - by Ken Whitesell
Ken questions the performance claim made by Thomas Loiret. He writes,
It is easy to lose sight of the fact that SQL itself is an abstraction layer for the database.
Making judgments about the relative performance of two SQL statements is not trivial and cannot be accurately or definitively made without going beyond the SQL statement itself.
Everything from the characteristics of a particular application's data to the hardware it runs on will impact performance. It is nice to see Ken's thoroughness in running benchmarks to demonstrate that Loiret's claim does not hold true.
Speeding up GROUP BY in PostgreSQL - by Hans-Jürgen Schönig, Cybertek
The order of the columns in the GROUP BY clause can impact the performance of the query. Again, this is a based on the characteristics of the application's data.
PyPodcats Episode 10 - A new trailer is here to tease us about an upcoming interview with Una Galyeva. I can't wait for the full interview!