Named windows let you reuse the same window definition in multiple places in your query. This saves time and keeps your query neat.
Named windows with WINDOW clause in PostgreSQL
WINDOW window_name AS (window_definition)The WINDOW clause is placed after the FROM clause and before ORDER BY.
You can define multiple named windows separated by commas.
w that groups rows by department and orders them by salary descending.WINDOW w AS (PARTITION BY department ORDER BY salary DESC)
w in the RANK() function to rank employees by salary within each department.SELECT name, salary, RANK() OVER w FROM employees WINDOW w AS (PARTITION BY department ORDER BY salary DESC);
w1 partitions by category, w2 orders by date.WINDOW w1 AS (PARTITION BY category), w2 AS (ORDER BY date)
This example creates a sales table, inserts some data, and then uses a named window w to calculate total sales and rank within each region.
CREATE TABLE sales ( id SERIAL PRIMARY KEY, region TEXT, amount INT ); INSERT INTO sales (region, amount) VALUES ('North', 100), ('South', 150), ('North', 200), ('South', 120), ('East', 130); SELECT region, amount, SUM(amount) OVER w AS total_region_sales, RANK() OVER w AS rank_in_region FROM sales WINDOW w AS (PARTITION BY region ORDER BY amount DESC);
Named windows help avoid repeating the same partition and order clauses multiple times.
You can refer to a named window inside another window definition by using WINDOW new_name AS (existing_name [frame]).
Named windows let you define window specifications once and reuse them.
This makes queries shorter, clearer, and easier to maintain.
Use the WINDOW clause after FROM and before ORDER BY.
Practice
WINDOW clause in PostgreSQL?Solution
Step 1: Understand the role of WINDOW clause
The WINDOW clause allows defining named window specifications once for reuse.Step 2: Compare options with WINDOW clause purpose
Options A, B, and C describe other SQL features, not the WINDOW clause.Final Answer:
To define named window specifications for reuse in the query -> Option CQuick Check:
WINDOW clause = named window reuse [OK]
- Confusing WINDOW with temporary tables
- Thinking WINDOW orders rows directly
- Mixing WINDOW with JOIN operations
w1 that orders rows by date ascending?Solution
Step 1: Recall WINDOW clause syntax
The correct syntax is WINDOW name AS (window_definition), e.g., WINDOW w1 AS (ORDER BY date ASC).Step 2: Check each option's syntax
WINDOW w1 AS (ORDER BY date ASC) matches correct syntax. Options A, B, and D have incorrect keyword order or missing AS.Final Answer:
WINDOW w1 AS (ORDER BY date ASC) -> Option BQuick Check:
WINDOW name AS (definition) syntax [OK]
- Omitting AS keyword
- Using BY instead of ORDER BY
- Misplacing parentheses
SELECT department, employee, salary, AVG(salary) OVER w AS avg_salary FROM employees WINDOW w AS (PARTITION BY department ORDER BY employee) ORDER BY department, employee;
What does the
avg_salary column show?Solution
Step 1: Analyze the WINDOW clause
The window named w partitions rows by department and orders by employee.Step 2: Understand AVG() OVER w behavior
AVG(salary) OVER w calculates the average salary for rows in the same department up to the current employee in order.Final Answer:
The average salary of employees in the same department up to the current employee -> Option AQuick Check:
Partition + order = running average per department [OK]
- Ignoring ORDER BY in window
- Assuming average over entire table
- Confusing partition with no partition
SELECT name, salary, SUM(salary) OVER w FROM employees WINDOW w AS (PARTITION BY department ORDER BY name BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW);
It returns an error. What is the likely cause?
Solution
Step 1: Check window frame syntax
The frame clause must specify ROWS or RANGE explicitly before frame boundaries.Step 2: Identify error cause
The query has ORDER BY name BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, missing the required ROWS or RANGE keyword before BETWEEN.Final Answer:
The window frame clause requires ROWS or RANGE keyword explicitly -> Option AQuick Check:
Window frame needs ROWS or RANGE keyword [OK]
- Placing WINDOW clause after ORDER BY
- Omitting ROWS or RANGE keyword
- Using window name incorrectly in OVER
Solution
Step 1: Understand cumulative sum window frame
Cumulative sum requires a frame from the start to current row, so use RANGE or ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW.Step 2: Check window definition correctness
DefineWINDOW sales_win AS (PARTITION BY region ORDER BY date RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)and useSUM(sales) OVER sales_wincorrectly defines WINDOW with PARTITION BY region, ORDER BY date, and RANGE frame for cumulative sum.Step 3: Compare with other options
DefineWINDOW sales_win AS (PARTITION BY region ORDER BY date ROWS UNBOUNDED PRECEDING)and useSUM(sales) OVER sales_winuses ROWS UNBOUNDED PRECEDING which sums the entire partition, not cumulatively. DefineWINDOW sales_win AS (ORDER BY date PARTITION BY region)and useSUM(sales) OVER sales_winhas wrong order of clauses. UseSUM(sales) OVER (PARTITION BY region ORDER BY date)without WINDOW clause does not reuse named window.Final Answer:
Define WINDOW sales_win AS (PARTITION BY region ORDER BY date RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) and use SUM(sales) OVER sales_win -> Option DQuick Check:
Named window with correct frame = DefineWINDOW sales_win AS (PARTITION BY region ORDER BY date RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)and useSUM(sales) OVER sales_win[OK]
- Omitting frame clause for cumulative sum
- Incorrect order of PARTITION BY and ORDER BY
- Not using named window for reuse
Ready to prove it?
Pass the test and this pattern moves unknown
