Re: pg9.4 relpages of child tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg9.4 relpages of child tables
Date
Msg-id 25865.1426695082@sss.pgh.pa.us
Whole thread Raw
In response to pg9.4 relpages of child tables  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: pg9.4 relpages of child tables  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> 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.

I don't see any difference in the behavior of HEAD and 9.0 on this point.

> Documentation indicates that in pg9.0, ANALYZE of a parent table included
> statistics of its children.

Well, ANALYZE on a parent table will collect statistics for that table
as well as some "whole tree" statistics that cover parent plus children;
but the latter are just data distribution stats entered into pg_statistic.
I don't see any indication that any PG version will update the childrens'
relpages values while doing that.

I suspect that you're getting confused because autovacuum kicked in on the
child and updated those stats behind your back.  For me, the child's
relpages reads as zero even after the ANALYZE, but if I wait a minute or
so, it changes to a nonzero value because the autovacuum daemon updated
it.

See also the "future directions" thread nearby.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: parallel mode and parallel contexts
Next
From: Robert Haas
Date:
Subject: Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0