I believe there's been a behavior change, and not sure if it's deliberate. I
don't think there's a negative consequence for our production use, but it
confused me while summing relpages for analysis purposes, as our 9.4 customers
behaved differently.
Documentation indicates that in pg9.0, ANALYZE of a parent table included
statistics of its children.
Under both pg9.3 and 9.4, this returns no stats rows, after the parent table is
analyzed. It returns stats if the child is analyzed.SELECT * FROM pg_statistic WHERE starelid='.._2014_01'::regclass
However, in pg9.4, the child's pg_class.relpages is 0 (apparently, 1 for
indices) even after the parent is analyzed (and is an approximate number of
pages if the child is analyzed).
On pg93:
pryzbyj=# create table t (i int);
pryzbyj=# create table t2 (like t) inherits(t);
pryzbyj=# insert into t2(SELECT generate_series(1,100000) ORDER BY RANDOM());
pryzbyj=# select relpages from pg_class where relname='t2';=> 0
pryzbyj=# analyze t;
pryzbyj=# select relpages from pg_class where relname='t2';=> 885
On pg94:
ts=# create table t (i int);
ts=# create table t2 (like t) inherits(t);
ts=# insert into t2(SELECT generate_series(1,100000) ORDER BY RANDOM());
ts=# select relpages from pg_class where relname='t2';=> 0
ts=# analyze t;
ts=# select relpages from pg_class where relname='t2'; -- this changed=> 0
ts=# analyze t2;
ts=# select relpages from pg_class where relname='t2';=> 443
Is that a deliberate change, and if so, is there any documentation of it? I'd
prefer to avoid analyzing all our child tables, as all queries hit the parents,
which include statistics on the children.
Thanks,
Justin
