Ajustando as constantes de custo do planejador de consultas
Aprenda como constantes de custo do planejador, como random_page_cost e effective_cache_size, influenciam as escolhas de plano e como ajustá-las ao seu hardware e aos seus dados.
Ajustando as constantes de custo do planejador de consultas é uma aula grátis de PostgreSQL Performance & Query Optimization no CoddyKit. Esta é a aula 4 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.
The Planner Needs Hints About Hardware
The planner estimates the cost of each plan using constants that model your hardware. If those constants do not match reality, it may pick a sequential scan when an index scan would be far faster, or vice versa.
seq_page_cost vs random_page_cost
Two key constants:
seq_page_cost(default 1.0): cost to read a page sequentiallyrandom_page_cost(default 4.0): cost to read a page at random
The 4:1 ratio assumes spinning disks where random reads are slow.
Tuning for SSDs
On SSDs random reads are nearly as cheap as sequential ones. Lowering random_page_cost makes the planner favor index scans appropriately.
SET random_page_cost = 1.1;effective_cache_size
This tells the planner how much memory the OS and PostgreSQL together are likely to use for caching data. It does not allocate memory — it only influences cost estimates for index scans.
SET effective_cache_size = '12GB';Why effective_cache_size Matters
A large value tells the planner that repeated index lookups will likely hit cache, making index scans look cheaper and more attractive for large tables. Set it to roughly 50-75% of total RAM.
CPU Cost Constants
Finer constants weigh CPU work:
cpu_tuple_cost: per-row processingcpu_index_tuple_cost: per index entrycpu_operator_cost: per operator/function call
These are rarely changed but matter for CPU-heavy expressions.
Testing a Change at Session Level
Test constants with SET in your session before making them permanent. Compare plans with EXPLAIN.
SET random_page_cost = 1.1;
EXPLAIN SELECT * FROM orders WHERE customer_id = 42;Making It Permanent
Once satisfied, set the value cluster-wide and reload, or edit postgresql.conf.
ALTER SYSTEM SET random_page_cost = 1.1;
SELECT pg_reload_conf();Beware of Over-Tuning
Do not chase a single slow query by skewing constants globally — you may break thousands of other plans. Fix the root cause (missing index, stale stats) first; adjust constants only for genuine hardware mismatches.
Per-Tablespace Tuning
If some data sits on SSD and some on HDD, you can set random_page_cost per tablespace so the planner reasons about each storage medium correctly.
ALTER TABLESPACE fast_ssd
SET (random_page_cost = 1.1);Verifying the Effect
After changing a constant, confirm the planner actually switched plans. Run EXPLAIN before and after and look for a Seq Scan turning into an Index Scan (or vice versa).
EXPLAIN SELECT * FROM orders WHERE customer_id = 42;
SET random_page_cost = 1.1;
EXPLAIN SELECT * FROM orders WHERE customer_id = 42;Quick Check
Test your planner-tuning knowledge.
Recap
You learned planner cost tuning:
- Cost constants model your hardware for the planner
- Lower
random_page_coston SSDs to favor index scans - Set
effective_cache_sizeto ~50-75% of RAM - Test with
SETand EXPLAIN beforeALTER SYSTEM - Fix indexes/stats before skewing constants globally
Aprenda SQL com um tutor de IA — grátis
Escreva e execute código real no seu navegador, obtenha ajuda instantânea de um tutor de IA 24/7 e continue de onde parou na web ou no app.
- Cursos
- 22
- Aulas
- 88
Perguntas Frequentes
A aula “Ajustando as constantes de custo do planejador de consultas” é grátis?
Sim — o texto completo de “Ajustando as constantes de custo do planejador de consultas” é 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 “Ajustando as constantes de custo do planejador de consultas”?
Aprenda como constantes de custo do planejador, como random_page_cost e effective_cache_size, influenciam as escolhas de plano e como ajustá-las ao seu hardware e aos seus dados. 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 4 de 4.
Quanto tempo leva a aula “Ajustando as constantes de custo do planejador de consultas”?
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
- Principais parâmetros do postgresql.conf
- Ajuste de memória (shared_buffers, work_mem)
- Ajuste de E/S de disco e pontos de verificação
- Ajustando as constantes de custo do planejador de consultas