From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | yuzuko <yuzukohosoya(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Amit Langote <amitlangote09(at)gmail(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Greg Stark <stark(at)mit(dot)edu> |
Subject: | Re: Autovacuum on partitioned table (autoanalyze) |
Date: | 2021-04-06 20:56:49 |
Message-ID: | 20210406205649.GA20523@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Apr-04, Tomas Vondra wrote:
> 1) I still don't understand why inheritance and declarative partitioning
> are treated differently. Seems unnecessary nad surprising, but maybe
> there's a good reason?
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.
I'm working on the code to fix the other issues.
--
Álvaro Herrera 39°49'30"S 73°17'W
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2021-04-06 21:29:01 | Re: psql - add SHOW_ALL_RESULTS option |
Previous Message | Zhihong Yu | 2021-04-06 20:56:19 | Re: Parallel Full Hash Join |