Re: Autovacuum on partitioned table (autoanalyze)

Hello,

Thank you for reviewing.
I'm working on fixing the patch according to the comments.
I'll send it as soon as I can.

> On 2021-04-06 16:56:49 -0400, Alvaro Herrera wrote:
> > I think there is a good reason to treat them the same: pgstat does not
> > have a provision to keep stats both of the table with children, and the
> > table without children. It can only have one of those. For
> > partitioning that doesn't matter: since the table-without-children
> > doesn't have anything on its own (no scans, no tuples, no nothing) then
> > we can just use the entry to store the table-with-children data. But
> > for the inheritance case, the parent can have its own tuples and counts
> > its own scans and so on; so if we change things, we'll overwrite the
> > stats. Maybe in the long-term we should allow pgstat to differentiate
> > those cases, but that seems not in scope for this patch.
>
> FWIW, I think it shouldn't be too hard to do that once the shared memory
> stats patch goes in (not 14, unfortunately). The hardest part will be to
> avoid exploding the number of interface functions, but I think we can
> figure out a way to deal with that.
>
I've been thinking about traditional inheritance, I realized that we
need additional
handling to support them because unlike declarative partitioning,
parents may have
some rows in the case of traditional inheritance as Alvaro mentioned.
So I think we should support only declarative partitioning in this
patch for now,
but what do you think? I'm not sure but if we can solve this matter
at low cost by
using the shared memory stats patch, should we wait for the patch?

--
Best regards,
Yuzuko Hosoya
NTT Open Source Software Center