On 3/29/21 9:24 PM, Tomas Vondra wrote:
>
>
> On 3/29/21 8:36 PM, Justin Pryzby wrote:
>> Thanks for taking a fresh look at this.
>>
>> As you've written it, this can apply to either/both partitioned or inheritence.
>> I imagine when "MERGE" goes away, this should apply only to partitioned tables.
>> (Actually, personally I would advocate to consider applying it to *both*, but I
>> don't think that's been the tendency over the last 4 years. I wrote here about
>> some arguably-gratuitous differences between inheritence and partitioning.
>> https://www.postgresql.org/message-id/20180601221428.GU5164@telsasoft.com)
>>
>
> Haven't thought about that too much at this point, but I don't see any
> reason to not apply it only to both cases. I might be missing something,
> but the fact that with declarative partitioning we analyze the children,
> while with inheritance we don't, seems a bit strange. Not sure.
>
BTW I'm not sure the "merge" will / should go away. What I'd expect is
that we'll keep it, and you can do either "ANALYZE" or "ANALYZE
(MERGE)". The former does regular sampling, while the latter does the
proposed merging of stats.
For the autovacuum, I think a new autovacuum_analyze_merge GUC and
reloption would work - chances are people will want to set the default
and then maybe enable merging only for some cases. Not sure.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company