0Pricing
PostgreSQL Performance & Query Optimization · Aula

Subconsulta versus CTE versus junções

Compare subconsultas, Expressões de Tabela Comum (CTEs) e junções para construir consultas de forma ideal.

Subconsulta versus CTE versus junções é uma aula grátis de PostgreSQL Performance & Query Optimization no CoddyKit. Esta é a aula 3 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de PostgreSQL Performance & Query Optimization, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de PostgreSQL Performance & Query Optimization inclui 4 aulas no total.

Partes desta aula ainda não foram traduzidas e aparecem em inglês.

Welcome to Query Construction

In this lesson, we'll explore three fundamental ways to combine and structure data in PostgreSQL: Subqueries, Common Table Expressions (CTEs), and Joins.

Understanding their differences and optimal use cases is key to writing efficient and readable SQL.

Joins: The Foundation

You're already familiar with JOINs! They are the primary way to combine rows from two or more tables based on a related column between them.

  • Purpose: Link related data across tables.
  • Readability: Often straightforward for direct relationships.
  • Performance: Highly optimized by PostgreSQL for combining large datasets.

What are Subqueries?

A subquery (or inner query) is a query nested inside another SQL query. It can return a single value (scalar), a single row, a single column, or a table.

  • Placement: In SELECT, FROM, WHERE, or HAVING clauses.
  • Use Cases: Filtering with IN/EXISTS, calculating aggregate values for comparison, or providing derived tables.

Subquery in Action

Here's a simple example where a subquery helps find products with prices above the average. Notice how the inner query runs first.

CREATE TABLE products (
  product_id SERIAL PRIMARY KEY,
  product_name VARCHAR(50),
  price DECIMAL(10, 2)
);

INSERT INTO products (product_name, price) VALUES
('Laptop', 1200.00),
('Mouse', 25.00),
('Keyboard', 75.00),
('Monitor', 300.00),
('Webcam', 50.00);

SELECT product_name, price
FROM products
WHERE price > (SELECT AVG(price) FROM products);

DROP TABLE products;

What are CTEs?

A Common Table Expression (CTE), defined with the WITH clause, creates a temporary, named result set that you can reference within a single SQL statement.

  • Purpose: Improve readability, organize complex queries, and enable recursion.
  • Scope: Only available for the query immediately following the WITH clause.
  • Readability: Breaks down complex logic into logical, readable steps.

CTE in Action

Let's rewrite the previous example using a CTE. Notice how it defines "average_price" first, making the main query clearer.

CREATE TABLE products (
  product_id SERIAL PRIMARY KEY,
  product_name VARCHAR(50),
  price DECIMAL(10, 2)
);

INSERT INTO products (product_name, price) VALUES
('Laptop', 1200.00),
('Mouse', 25.00),
('Keyboard', 75.00),
('Monitor', 300.00),
('Webcam', 50.00);

WITH AverageProductPrice AS (
  SELECT AVG(price) AS avg_price
  FROM products
)
SELECT p.product_name, p.price
FROM products p, AverageProductPrice app
WHERE p.price > app.avg_price;

DROP TABLE products;

Choosing Joins

JOINs are your go-to when you need to combine data from different tables that have a direct, logical relationship.

  • Direct Relationships: When tables are linked by foreign keys.
  • Performance: Highly optimized by the planner for combining large datasets efficiently.
  • Result Set: Creates a single, wider result set from matching rows.

They are often the most performant for combining large tables.

Choosing Subqueries

Subqueries are useful for specific filtering or calculating values that depend on the main query's data, often acting as a single value or a list.

  • Scalar Values: When you need a single value (e.g., WHERE price > (SELECT AVG(price))).
  • Filtering: With IN, NOT IN, EXISTS, NOT EXISTS clauses.
  • Derived Tables: In the FROM clause for temporary, unnamed result sets.

They can sometimes be less readable for complex logic.

Choosing CTEs

CTEs excel when you need to break down complex queries into logical, readable steps or handle recursive data structures.

  • Readability: Improves understanding of multi-step logic.
  • Recursion: Essential for querying hierarchical or graph-like data.
  • Reusability: A CTE can be referenced multiple times within the same main query.

They are often preferred over complex subqueries for clarity.

Performance: It's Complicated!

Often, a query written with a subquery can be rewritten as a JOIN or a CTE, and vice-versa. PostgreSQL's optimizer is smart!

  • Optimizer Role: It often transforms these constructs internally into the most efficient execution plan.
  • Readability First: Prioritize clear, maintainable code.
  • EXPLAIN ANALYZE: Always use it to truly understand the performance impact of your chosen approach, rather than guessing.

Compare & Contrast

Consider the following scenarios. Which SQL construct is generally the most suitable choice for each?

Recap: Constructing Optimal Queries

You've learned to differentiate between JOINs, Subqueries, and CTEs:

  • JOINs: Best for direct table relationships and combining large datasets.
  • Subqueries: Ideal for scalar values, IN/EXISTS filtering, and derived tables.
  • CTEs: Shine for readability, multi-step logic, and recursive queries.

Remember to prioritize readability and use EXPLAIN ANALYZE to confirm performance!

Perguntas Frequentes

A aula “Subconsulta versus CTE versus junções” é grátis?

Sim — o texto completo de “Subconsulta versus CTE versus junções” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de PostgreSQL Performance & Query Optimization, atualize para CoddyKit PRO. O curso de PostgreSQL Performance & Query Optimization inclui 4 aulas no total.

O que vou aprender em “Subconsulta versus CTE versus junções”?

Compare subconsultas, Expressões de Tabela Comum (CTEs) e junções para construir consultas de forma ideal. Você pratica PostgreSQL Performance & Query Optimization com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar PostgreSQL Performance & Query Optimization?

Nenhuma experiência prévia é necessária. PostgreSQL Performance & Query Optimization no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 3 de 4.

Quanto tempo leva a aula “Subconsulta versus CTE versus junções”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de PostgreSQL Performance & Query Optimization?

Sim. Cada aula de PostgreSQL Performance & Query Optimization inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. Entendendo os algoritmos de junção
  2. Reescrevendo junções complexas
  3. Subconsulta versus CTE versus junções
  4. Otimizando junções LATERAL e buscas correlacionadas
← Voltar para PostgreSQL Performance & Query Optimization