Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jP5MP-0000T7-RQ for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Apr 2020 14:19:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jP5MO-0002eH-Bs for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Apr 2020 14:19:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jP5MO-0002dj-0t for pgsql-hackers@lists.postgresql.org; Thu, 16 Apr 2020 14:19:20 +0000 Received: from mail-qk1-x741.google.com ([2607:f8b0:4864:20::741]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jP5MK-00078M-VP for pgsql-hackers@lists.postgresql.org; Thu, 16 Apr 2020 14:19:19 +0000 Received: by mail-qk1-x741.google.com with SMTP id l78so5709502qke.7 for ; Thu, 16 Apr 2020 07:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=uqHp5d3QXZrHkJ/vefQiYHpOo96QxhyiJr02uA+XBvA=; b=Cw8aCQymPWYQMawLNsdxfxln1wit6fAqcnR6fpssC1fgVEFcnVouuJ7G2OCmkGefoM ZXp7tquKaSz6Q1Rkl2q1OH8lLMF5i4CwS8ADuhZqapkQwifoelVjEbvFapXoDkGc6kuM qu5yfztQFez8EEHRjKFoZTPMgljzOsAjiAcCEpt6AfoKdYeXbBBsjoAXBX+wLrhrEt0C IaCET0gCIfOmlfQmH5ZbkhNpNbnM49+/7Pre/qq2AUttLml2WFaaVq9/h3L17NS7Hk5P hhddwFztUe9kZfb9qIHBKV6DM9OG6KE82BIlmKggHT12ommQANakmH4joKzzshdbn9GG MFBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uqHp5d3QXZrHkJ/vefQiYHpOo96QxhyiJr02uA+XBvA=; b=GLtQ5n/40vCbBGXEK0MPzMDaUYZkWih32COi9LzG+Grd0MDHD+4zap+vjje5x+4cjz SqNN30sxAeGk4UmNve8lqlIGjXXOiv3Uu58iOBv02Zmm+GujcTEuhDyI4SueRMtZdboL wrC/2CYQUo5h1Zxx83SQ8AnlC7KO3y+eiVInKZG/0Iq5H4U5wN0SGjEaUiL3lu4BJd+H i7FI2xAoknx0tjld8bVflJ4/hA2yCTcJXAhGcBPZeHEFyIwH7LNuF+Sz268AGGyQxz1q vZ65Rp9Ab3bETI1Sg0Xxg+cslD7Un0TKoUb5h9Nd5eMvVs8sHHeRor9Uo+jR5GHIwJpi iR5Q== X-Gm-Message-State: AGi0Pub8PyQDd2sTsA0Qhvl9xSUVKQJAcGHhBVeTU0Il9qAh8eoIr8PI lcbk6qK7BCRE6a0kp9vwkK7Gcg== X-Google-Smtp-Source: APiQypIavuQjfI6kLvKmWH0O5RMVaFbszejZLzohM1s+KbGuTq363v4qTx5HhPT6fvCJjeWzQOlFwA== X-Received: by 2002:a37:7fc3:: with SMTP id a186mr31829758qkd.251.1587046754689; Thu, 16 Apr 2020 07:19:14 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id p47sm12698672qta.44.2020.04.16.07.19.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2020 07:19:13 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 31BC0800A81; Thu, 16 Apr 2020 09:19:11 -0500 (CDT) Date: Thu, 16 Apr 2020 09:19:11 -0500 From: Justin Pryzby To: yuzuko Cc: Amit Langote , Alvaro Herrera , Masahiko Sawada , Laurenz Albe , pgsql-hackers@lists.postgresql.org, Greg Stark Subject: Re: Autovacuum on partitioned table (autoanalyze) Message-ID: <20200416141910.GM2228@telsasoft.com> References: <20200228022545.GA19686@alvherre.pgsql> <20200318163039.GL26184@telsasoft.com> <20200407033256.GG2228@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Apr 16, 2020 at 06:16:45PM +0900, yuzuko wrote: > > I think it ought to be possible to configure this feature such that an > > auto-analyze on any child partition would trigger analyze of the parent. I > > think that would be important for maintaining accurate stats of the partition > > key column for many cases involving RANGE-partitioned tables, which are likely > > to rely on histogram rather than MCVs. > > I read your previous email and understand that it would be neccesary to analyze > partitioned tables automatically when any of its children are analyzed. In my > first patch, auto-analyze on partitioned tables worked like this but there were > some comments about performance of autovacuum, especially when partitioned > tables have a lot of children. I reread that part. There was also confusion between autovacuum vacuum and autovacuum analyze. I agree that it *might* be a problem to analyze the parent every time any child is analyzed. But it might also be what's needed for this feature to be useful. > The latest patch lets users set different autovacuum configuration for > each partitioned > tables like this, > create table p3(i int) partition by range(i) with > (autovacuum_analyze_scale_factor=0.0005, autovacuum_analyze_threshold=100); > so users can configure those parameters according to partitioning strategies > and other requirements. > > So I think this patch can solve problem you mentioned. I don't think that adequately allows what's needed. I think it out to be possible to get the "analyze parent whenever a child is analyzed" behavior easily, without having to compute new thershold parameters every time one adds partitions, detaches partitions, loades 10x more data into one of the partitions, load only 10% as much data into the latest partition, etc. For example, say a new customer has bunch of partitioned tables which each currently have only one partition (for the current month), and that's expected to grow to at least 20+ partitions (2+ years of history). How does one set the partitioned table's auto-analyze parameters to analyze whenever any child is analyzed ? I don't think it should be needed to update it every month after computing sum(child tuples). Possibly you could allow that behavior for some special values of the threshold. Like if autovacuum_analyze_threshold=-2, then analyze the parent whenever any of its children are analyzed. I think that use case and that need would be common, but I'd like to hear what others think. -- Justin