Re: pg9.4 relpages of child tables

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

In response to

Responses

Browse pgsql-hackers by date

  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