Preamble
The PostgreSQL COUNT function returns the number of expressions.
Syntax of the count function in PostgreSQL
SELECT count(aggregate_expression_id)
FROM tabs
[WHERE conds];
Or the syntax of the count function when grouping results in one or more columns:
SELECT expression1_id,2_id,..._n_id,
count(aggregate_expression_id)
FROM tabs
[WHERE conds]
GROUP BY expression1,2,..._n;
Parameters and arguments of the function
- expression1_id, expression2_id,… expression_n_id – Expressions that are not enclosed in the count function and must be included in the GROUP BY operator at the end of the SQL query.
- aggregate_expression_id – This is a column or expression whose non-zero values will be taken into account.
- tabs – These are the tables from which you want to get the records. At least one table must be specified in the FROM operator.
- WHERE conds – Optional. These are the conditions that must be met to select records.
Includes only NOT NULL values
Not everyone understands this, but the count function will only include entries in which the value of the expression in the count(expression) is NOT NULL. When an expression contains a value of NULL, it is not included in the count calculation.
Let’s look at an example of a count function that shows how NULL values are evaluated by the count function.
For example, if you have the following table with the name suppliers:
|
suppl_id
|
suppl_name
|
state
|
|---|---|---|
|
1
|
IBM
|
CA
|
|
2
|
Microsoft
|
|
|
3
|
NVIDIA
|
And if you run the next SELECT operator, which uses the count function:
SELECT count(suppl_id)
FROM suppls;
--Result: 3
This example count will return 3 because all supplier_id values in the resulting query set are not equal to NULL
However, if you run the next SELECT operator, which uses the count function:
SELECT count(state)
FROM suppls;
--Result: 1
In this example, the count will return only 1 since only one state value in the resulting NOT NULL query set. This will be the first line where state = ‘CA’. This is the only line that is included in the calculation of the count function.
The count function can be used in the following versions of PostgreSQL
PostgreSQL 11, PostgreSQL 10, PostgreSQL 9.6, PostgreSQL 9.5, PostgreSQL 9.4, PostgreSQL 9.3, PostgreSQL 9.2, PostgreSQL 9.1, PostgreSQL 9.0, PostgreSQL 8.4.
Single Expression Example
Let’s look at some examples of count functions to understand how to use the count function in PostgreSQL.
For example, you might want to know the number of entries from the products table that have a product_type ‘Hardware’
SELECT count(*) AS "Number of products"
FROM prods
WHERE prod_type = 'Hardware';
In this example of the count function, we called the expression count(*) as “Number of products”. As a result, “Number of products” will be displayed as a field name when the result set is returned.
Example using DISTINCT
You can use the DISTINCT operator in the count function. For example, the following SQL statement returns the number of unique departments (departments) where at least one employee earns more than $35000 per year.
SELECT count(DISTINCT depart) AS "Unique departs"
FROM empls
WHERE salary_id > 35000;
Again, the field count(DISTINCT department) has an alias “Unique departments”. This is the name of the field to be displayed in the result set.
Example using GROUP BY
In some cases, you will need to use GROUP BY operator with the count function.
For example, you can also use the count function to return records from a department (department name) and “Number of employees” (number of employees in the corresponding department), whose salary is more than $40,000 per year.
SELECT depart, count(*) AS "Number of empls"
FROM empls
WHERE salary_id > 40000
GROUP BY depart;
Since your SELECT operator has one column that is not encapsulated in the count function, you should use the GROUP BY operator. That’s why the department field shall be specified in the GROUP BY operator.
About Enteros
Enteros offers a patented database performance management SaaS platform. It proactively identifies root causes of complex business-impacting database scalability and performance issues across a growing number of clouds, RDBMS, NoSQL, and machine learning database platforms.
The views expressed on this blog are those of the author and do not necessarily reflect the opinions of Enteros Inc. This blog may contain links to the content of third-party sites. By providing such links, Enteros Inc. does not adopt, guarantee, approve, or endorse the information, views, or products available on such sites.
Are you interested in writing for Enteros’ Blog? Please send us a pitch!
RELATED POSTS
How Do Streaming Services Manage Database Bottlenecks For New Content Releases And Large Live Events?
- 22 September 2026
- Database Performance Management
Streaming platforms can monitor SQL workloads, query latency, transaction volume, resource usage, database waits, locking, and sudden workload changes to avoid database bottlenecks during major live events and content releases. Effective streaming database performance monitoring empowers IT teams to identify performance risks earlier, optimise inefficient queries, plan capacity, and deliver reliable user experiences in times … Continue reading “How Do Streaming Services Manage Database Bottlenecks For New Content Releases And Large Live Events?”
How Do Hospitals Stop Databases From Slowing Down At Emergency and High Patient Admission Times?
Hospitals can avoid database slowdowns during emergency and high-volume admission periods with continual monitoring of SQL workloads, transaction latency, database waits, locking, utilization of resources, connection levels and sudden workload changes. By effectively monitoring hospital database performance, healthcare IT teams can detect bottlenecks sooner, optimize inefficient queries, plan capacity, and maintain reliable access to vital … Continue reading “How Do Hospitals Stop Databases From Slowing Down At Emergency and High Patient Admission Times?”
How Can Banks Prevent Database Slowdowns During High Transaction Volumes?
- 21 September 2026
- Database Performance Management
Banks can protect bank database performance during high transaction volumes by monitoring SQL latency, throughput, locks, waits, CPU, memory, storage I/O, and workload changes continuously. Strong banking database performance also depends on optimizing high-impact queries, establishing baselines, detecting anomalies early, analyzing root causes, and forecasting capacity before demand exceeds available resources. Why Does Bank Database … Continue reading “How Can Banks Prevent Database Slowdowns During High Transaction Volumes?”
How Can Telecom Companies Improve Database Performance and Keep Networks Running Smoothly?
By regularly tracking SQL workloads, query latency, database waits, resource utilisation, locking, and capacity trends, telecom businesses can enhance the performance of their databases. Telecom teams may identify bottlenecks early, minimise service interruption, and maintain dependable customer-facing systems with the use of efficient database performance monitoring. Enteros facilitates proactive performance management by utilising analytics, root … Continue reading “How Can Telecom Companies Improve Database Performance and Keep Networks Running Smoothly?”