From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg9.4 relpages of child tables |
Date: | 2015-03-18 16:11:22 |
Message-ID: | 25865.1426695082@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Justin Pryzby <pryzby(at)telsasoft(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Svenne Krap | 2015-03-18 16:18:02 | Re: WIP Patch for GROUPING SETS phase 1 |
Previous Message | Robert Haas | 2015-03-18 16:02:07 | Re: parallel mode and parallel contexts |