On Thu, Dec 2, 2021 at 9:24 PM Justin Pryzby <pry...@telsasoft.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
