Horton

Re: extended stats on partitioned tables

Zhihong Yu <zyu@yugabyte.com>

View thread View on postgr.es
From: Zhihong Yu <zyu@yugabyte.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>, Jaime Casanova <jcasanov@systemguards.com.ec>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-12-03T17:15:28Z
Lists: pgsql-hackers 
On Thu, Dec 2, 2021 at 9:24 PM Justin Pryzby <pryzby@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

Commits

  1. Add stxdinherit flag to pg_statistic_ext_data

  2. Build inherited extended stats on partitioned tables

  3. Ignore extended statistics for inheritance trees

  4. Don't build extended statistics on inheritance trees

  5. Tighten up relation kind checks for extended statistics

  6. Avoid assuming that statistics for a parent relation reflect the properties of