Question Details

No question body available.

Tags

postgresql alibaba-cloud polardb

Answers (3)

February 9, 2026 Score: 0 Rep: 30,392 Quality: Medium Completeness: 80%

Those stats include the partition stats - you don't need to create them for each partition separately if that's your concern. The parent table isn't really a table, without the partitions it has no data of its own so if that statistics object were to only cover the parent, it would be just empty.

Take a look at pgstatsext system view: demo at dbfiddle

create statistics statab (ndistinct,mcv) on a, b from teststat;
insert into teststat select 1+random()*198,random()*3 from generateseries(1,1e4);
select tableoid::regclass,count(*) from teststat group by 1;
tableoid count
teststatp2 5015
teststatp1 4985 
select schemaname,tablename,statisticsname,attnames,ndistinct,mostcommonvals 
from pgstatsext;
schemaname tablename statisticsname attnames ndistinct mostcommonvals
public teststat stat_ab {a,b} {"1, 2": 796} {{187,1},{122,1},{77,1},{43,1},{82,2},{2,2},{19,2},{185,1},{155,1},{155,2},{113,2},{52,2},{44,1},{138,1},{95,1},{7,2},{68,2},{46,2},{30,1},{64,1},{26,2},{126,2},{159,1},{19,1},{37,1},{188,1},{65,1},{173,1},{141,2},{116,1},{75,1},{44,2},{143,2},{8,2},{115,2},{71,1},{4,1},{89,1},{3,2},{175,2},{14,1},{65,2},{117,2},{181,1},{56,1},{119,1},{150,2},{162,2},{184,2},{135,1},{107,1},{105,2},{161,1},{150,1},{13,1},{16,2},{20,2},{21,1},{22,1},{27,1},{31,2},{47,2},{53,2},{182,2},{58,1},{178,1},{80,1},{87,1},{165,2},{114,1},{130,1},{132,2},{11,1},{11,2},{158,2},{137,1},{6,1},{60,2},{179,2},{142,2},{170,2},{100,1},{195,1},{183,1},{191,1},{154,2},{24,2},{134,2},{3,1},{145,1},{165,1},{36,1},{177,1},{192,1},{118,1},{69,1},{151,1},{115,1},{180,1},{60,1}}

These cover both partitions.

February 9, 2026 Score: 0 Rep: 30,392 Quality: Medium Completeness: 100%

When the planner estimates costs for queries on a partition/child table, how are these statistics actually used?

High level how in the doc:

Low level actually how, in the source: postgres/src/backend/optimizer/path/clausesel.c

Does it rely only on the child’s stats, or does it combine/use the parent’s stats in some way?

Both, otherwise there would be no reason to maintain them on the empty parent table. Whenever the whole structure needs to be considered, you need collective stats, so you look at the parent. Later, when you need to actually pull something from the underlying partitions, you'll check their individual stats.

Extended statistics take priority over the ones collected by default. You can adjust the built-in ones with alter table..alter column..set statistics and the extended ones using alter statistics..set statistics.

February 9, 2026 Score: 0 Rep: 1 Quality: Low Completeness: 50%

Thanks for your answer! I’ve verified it and it works exactly as you described, and it does solve the issue I was running into.

But this brings up another question: for the regular statistics (the ones visible in pg_stats), both the parent and the child tables have their own entries. When the planner estimates costs for queries on a partition/child table, how are these statistics actually used? Does it rely only on the child’s stats, or does it combine/use the parent’s stats in some way?

This might already be a different question, and I suspect the answer is buried somewhere in the planner code. However, this area is still unfamiliar to me, so it will probably take me some time to fully understand it. If you have any experience with how the planner uses parent vs. child statistics and are willing to share some insights or pointers, I’d really appreciate it.