HAVING for filtering groups in PostgreSQL - Deep Dive

Overview - HAVING for filtering groups

What is it?

HAVING is a command in SQL used to filter groups of rows after they have been grouped together. It works with the GROUP BY clause to allow conditions on aggregated data, like sums or counts. Unlike WHERE, which filters individual rows before grouping, HAVING filters the groups themselves. This helps find groups that meet specific criteria.

Why it matters

Without HAVING, you could only filter rows before grouping, making it impossible to select groups based on summary information like totals or averages. This would limit your ability to analyze data in meaningful ways, such as finding customers with more than five orders or products with total sales above a threshold. HAVING lets you ask questions about groups, not just single rows.

Where it fits

Before learning HAVING, you should understand basic SQL SELECT queries, filtering with WHERE, and grouping data with GROUP BY. After HAVING, you can explore advanced aggregation functions, window functions, and complex reporting queries that combine multiple filters and groupings.

Mental Model

Core Idea

HAVING filters groups created by GROUP BY based on conditions applied to aggregated data.

Think of it like...

Imagine sorting your mail into piles by sender (GROUP BY). HAVING is like deciding to keep only the piles where the total number of letters is more than five. You first group, then decide which groups to keep based on their size.

SELECT columns
  FROM table
  WHERE row_conditions
  GROUP BY grouping_columns
  HAVING group_conditions

Flow:
[Rows] --WHERE--> [Filtered Rows] --GROUP BY--> [Groups] --HAVING--> [Filtered Groups] --SELECT--> [Result]

Build-Up - 7 Steps

1

Foundation

Understanding GROUP BY basics

Concept: Learn how GROUP BY collects rows into groups based on column values.

GROUP BY takes rows that share the same value in specified columns and bundles them into groups. For example, grouping sales by product ID collects all sales of each product together. Aggregation functions like COUNT or SUM then summarize each group.

Result

Rows are organized into groups, each representing a unique value or combination of values from the grouping columns.

Understanding grouping is essential because HAVING works only on these groups, not on individual rows.

2

Foundation

Filtering rows with WHERE clause

Concept: WHERE filters individual rows before grouping happens.

The WHERE clause removes rows that don't meet certain conditions before any grouping or aggregation. For example, WHERE price > 100 filters out cheap items before grouping sales by product.

Result

Only rows passing the WHERE condition are included in groups.

Knowing WHERE filters rows first helps clarify why HAVING is needed to filter groups after aggregation.

3

Intermediate

Introducing HAVING for group filtering

🤔Before reading on: do you think WHERE can filter groups after aggregation or only individual rows? Commit to your answer.

Concept: HAVING filters groups after aggregation, unlike WHERE which filters rows before grouping.

After GROUP BY creates groups, HAVING applies conditions to these groups using aggregate functions. For example, HAVING COUNT(*) > 5 keeps only groups with more than five rows. This lets you filter based on group summaries.

Result

Only groups meeting the HAVING condition appear in the final result.

Understanding HAVING's role after grouping unlocks powerful queries that analyze group-level data.

4

Intermediate

Using aggregate functions in HAVING

🤔Before reading on: can HAVING use non-aggregated columns or only aggregates? Commit to your answer.

Concept: HAVING conditions usually involve aggregate functions like COUNT, SUM, AVG, MIN, MAX.

You can write HAVING clauses like HAVING SUM(sales) > 1000 or HAVING AVG(rating) >= 4. These conditions test the summary values of each group. Non-aggregated columns in HAVING must appear in GROUP BY.

Result

Groups are filtered based on their aggregated values, enabling complex data analysis.

Knowing HAVING works with aggregates clarifies how to write meaningful group filters.

5

Intermediate

Difference between WHERE and HAVING

Concept: WHERE filters rows before grouping; HAVING filters groups after aggregation.

If you want to exclude rows before grouping, use WHERE. If you want to exclude groups after aggregation, use HAVING. For example, WHERE price > 10 filters rows; HAVING COUNT(*) > 5 filters groups with more than five rows.

Result

Queries behave differently depending on which clause you use, affecting final results.

Distinguishing WHERE and HAVING prevents common mistakes in filtering data.

6

Advanced

Combining HAVING with multiple conditions

🤔Before reading on: do you think HAVING supports multiple conditions combined with AND/OR? Commit to your answer.

Concept: HAVING supports complex conditions using AND, OR, and parentheses.

You can write HAVING clauses like HAVING SUM(sales) > 1000 AND COUNT(*) > 5 to filter groups meeting multiple criteria. Use parentheses to control logic, e.g., HAVING (SUM(sales) > 1000 OR AVG(rating) > 4) AND COUNT(*) > 3.

Result

Groups are filtered precisely based on combined aggregate conditions.

Mastering complex HAVING conditions enables sophisticated group filtering.

7

Expert

Performance considerations with HAVING

🤔Before reading on: do you think HAVING filters data before or after aggregation in query execution? Commit to your answer.

Concept: HAVING filters groups after aggregation, which can impact query performance if not used carefully.

Since HAVING runs after grouping and aggregation, it processes all groups before filtering. This can be slow on large datasets. Using WHERE to reduce rows before grouping improves speed. Indexes on grouping columns also help. Understanding query plans reveals how HAVING affects execution.

Result

Efficient queries balance WHERE and HAVING to minimize data processed.

Knowing HAVING's place in execution helps write faster, scalable queries.

Under the Hood

When a SQL query with GROUP BY and HAVING runs, the database first applies WHERE to filter rows. Then it groups the remaining rows by specified columns. Next, it calculates aggregate functions for each group. Finally, HAVING filters these groups based on aggregate conditions. Only groups passing HAVING are returned. This sequence ensures HAVING works on summaries, not raw rows.

Why designed this way?

SQL was designed to separate row-level filtering (WHERE) from group-level filtering (HAVING) to keep query logic clear and efficient. Early SQL versions lacked HAVING, making group filtering hard. HAVING was added to allow conditions on aggregates without complex subqueries. This design balances expressiveness and performance.

Query Execution Flow:

[Input Rows]
    │
    ▼
[WHERE filters rows]
    │
    ▼
[GROUP BY groups rows]
    │
    ▼
[Aggregate functions compute]
    │
    ▼
[HAVING filters groups]
    │
    ▼
[SELECT final output]

Myth Busters - 4 Common Misconceptions

Quick: Does HAVING filter rows before grouping or groups after grouping? Commit to your answer.

Common Belief: HAVING filters individual rows just like WHERE does.

Reality: HAVING filters groups after aggregation, not individual rows.

Why it matters: Using HAVING to filter rows can cause unexpected results or errors because it only works on groups, leading to confusion and wrong data.

Quick: Can you use non-aggregated columns in HAVING without grouping by them? Commit to your answer.

Common Belief: You can use any column in HAVING without restrictions.

Reality: Non-aggregated columns in HAVING must appear in GROUP BY; otherwise, the query is invalid.

Why it matters: Ignoring this causes syntax errors or incorrect grouping, breaking queries.

Quick: Is HAVING always slower than WHERE? Commit to your answer.

Common Belief: HAVING is always slower than WHERE and should be avoided.

Reality: HAVING filters after aggregation, so it can be slower, but proper use with WHERE and indexes can optimize performance.

Why it matters: Avoiding HAVING altogether limits query power; understanding when to use it improves efficiency.

Quick: Does HAVING replace WHERE for all filtering needs? Commit to your answer.

Common Belief: HAVING can replace WHERE for all filtering, even on individual rows.

Reality: HAVING cannot replace WHERE because it only filters groups, not individual rows.

Why it matters: Misusing HAVING leads to incorrect data filtering and inefficient queries.

Expert Zone

1

HAVING can reference aliases defined in SELECT, but only in some SQL dialects like PostgreSQL, which can simplify complex queries.

2

Using HAVING without GROUP BY is allowed in some databases to filter aggregated results over the entire table, acting like a global filter.

3

Combining HAVING with window functions requires careful query structuring because window functions operate after HAVING in execution order.

When NOT to use

Avoid HAVING when filtering individual rows; use WHERE instead for better performance. For complex filtering on aggregates, consider using subqueries or CTEs (WITH clauses) to improve readability and optimization.

Production Patterns

In production, HAVING is often used to find top customers, filter products by sales thresholds, or detect anomalies in grouped data. It is combined with indexes on grouping columns and sometimes with materialized views to speed up repeated queries.

Connections

Aggregation functions

HAVING builds on aggregation functions by filtering groups based on their results.

Understanding aggregation functions deeply helps write precise HAVING conditions that analyze group summaries.

Subqueries

HAVING can sometimes be replaced or complemented by subqueries that filter aggregated data.

Knowing subqueries offers alternative ways to filter groups, useful when HAVING syntax is limited or complex.

Statistics and data summarization

HAVING filters groups based on summary statistics like sums or averages.

Recognizing HAVING as a tool for statistical filtering connects database queries to broader data analysis concepts.

Common Pitfalls

#1 Using WHERE to filter aggregated results instead of HAVING.

Wrong approach:

SELECT product_id, COUNT(*) FROM sales GROUP BY product_id WHERE COUNT(*) > 5;

Correct approach:

SELECT product_id, COUNT(*) FROM sales GROUP BY product_id HAVING COUNT(*) > 5;

Root cause:

Confusing WHERE and HAVING roles; WHERE cannot use aggregate functions.

#2 Using non-aggregated columns in HAVING without grouping by them.

Wrong approach:

SELECT product_id, SUM(sales) FROM sales GROUP BY product_id HAVING sales > 1000;

Correct approach:

SELECT product_id, SUM(sales) FROM sales GROUP BY product_id HAVING SUM(sales) > 1000;

Root cause:

Misunderstanding that HAVING conditions must use aggregates or grouped columns.

#3 Trying to filter groups without GROUP BY using HAVING incorrectly.

Wrong approach:

SELECT COUNT(*) FROM sales HAVING COUNT(*) > 10 GROUP BY product_id;

Correct approach:

SELECT product_id, COUNT(*) FROM sales GROUP BY product_id HAVING COUNT(*) > 10;

Root cause:

Incorrect order of clauses and misunderstanding that HAVING filters groups created by GROUP BY.

Key Takeaways

HAVING filters groups created by GROUP BY based on aggregate conditions, unlike WHERE which filters individual rows.

Use WHERE to reduce rows before grouping and HAVING to filter groups after aggregation for efficient queries.

HAVING conditions usually involve aggregate functions like COUNT, SUM, or AVG to test group summaries.

Misusing WHERE and HAVING leads to syntax errors or incorrect results; understanding their roles is crucial.

Performance improves by combining WHERE and HAVING wisely and using indexes on grouping columns.