Re: extended stats on partitioned tables

On Thu, Dec 2, 2021 at 9:24 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:

> On Thu, Nov 04, 2021 at 12:44:45AM +0100, Tomas Vondra wrote:
> > >> And I'm not sure we do the right thing after removing children, for
> example
> > >> (that should drop the inheritance stats, I guess).
>
> > > Do you mean for inheritance only ? Or partitions too ?
> > > I think for partitions, the stats should stay.
> > > And for inheritence, they can stay, for consistency with partitions,
> and since
> > > it does no harm.
> >
> > I think the behavior should be the same as for data in pg_statistic,
> > i.e. if we keep/remove those, we should do the same thing for extended
> > statistics.
>
> That works for column stats the way I proposed for extended stats: child
> stats
> are never removed, neither when the only child is dropped, nor when
> re-running
> analyze (that part is actually a bit odd).
>
> Rebased, fixing an intermediate compile error, and typos in the commit
> message.
>
> --
> Justin
>
Hi,

+ if (!HeapTupleIsValid(tup)) /* should not happen */
+ // elog(ERROR, "cache lookup failed for statistics data %u",
statsOid);

You may want to remove commented out code.

+ for (i = 0; i < staForm->stxkeys.dim1; i++)
+ keys = bms_add_member(keys, staForm->stxkeys.values[i]);

Since the above code is in a loop now, should keys be cleared across the
outer loop iterations ?

Cheers