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 1lUzdi-0007eH-GC for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Apr 2021 22:30:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lUzdg-0000M7-5Y for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Apr 2021 22:30:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lUzdf-0000IN-Uq for pgsql-hackers@lists.postgresql.org; Fri, 09 Apr 2021 22:30:07 +0000 Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lUzdZ-0004Cj-61 for pgsql-hackers@lists.postgresql.org; Fri, 09 Apr 2021 22:30:06 +0000 Received: by mail-io1-xd34.google.com with SMTP id x16so7503490iob.1 for ; Fri, 09 Apr 2021 15:30:01 -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=++HD3B3PtWLwnwiYLxX/CAAXWui9u0lznMAG3VzAOqY=; b=k3WTf2j0kId1Anx82Bow20R/kHZxxazzcxZMxrCnxU9UxhAK3crYJey3u68l1n5m5l hmwjyJuXjKsvMBJYRfPN+xKIEr40doY+HUfpcWC9nRdYWsMXjDNu6oTzUERYBIXUF8n/ tsb1na3x6reGaoU3HOUCz/+dZ9ugzH0hhq6FrMb7e8VrziIFfwpJ85PKmYHQprQsmGep MkwaKTK0wXEwde5k5fPajhlWOi0sxEokb6HmSTN8YZc3fIW40WbGKzBJesZMWBR+etMd ElVlulTIryqhE7QgkLlLDpf7kdW1POrSFWzqNXk2RGIxOPutWgB/RDOkFnKX5GXPbQKk Rijw== 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=++HD3B3PtWLwnwiYLxX/CAAXWui9u0lznMAG3VzAOqY=; b=SuzWUq80fG+xozGpUWUQxnPx0UPDWUOl8PG980PNxGu7LS49tZkefsPwN8o/nMBNfT LtaM9sbF0/Xa6dvjP3xIv4dWsP8DYDkXmbAtH8NLoPoLf2iwVSk7OCXwHTNrGmEW0+nP AQ0caZGuD8d8Lnt9FjY1CEWil03LOSviVaDRWB4vZG73eQBdC3wHUo5CC+CVHTO7JNyK vCUklQWAjpCiUPdgwIR4TmzafKmGZpcnyEf0UmwBvr9vSbngFdrI8XqO/qDt/qASCSyi aTfmLpBvkA0dhTYPB7bzfriv1rp+i6j+ZSYyHIlM3gSCbv32l/6+AWH/GaykvXDDtE1L MhsA== X-Gm-Message-State: AOAM530gM1BvMOgpfm0lamVaHV5AYuYEpReJmrW8HwAHNjZAa+MPZFxJ RCYVen1U797prxjhnkz/WPanUg== X-Google-Smtp-Source: ABdhPJxsxuPGhcYkawbw/Vd8fVrNXLfuNZLVDe5bSdRivCP53FUtjW1GCRnRtF5HEpwQWM0zwrhkCw== X-Received: by 2002:a05:6638:606:: with SMTP id g6mr16959727jar.52.1618007400069; Fri, 09 Apr 2021 15:30:00 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id t9sm1798843ioi.27.2021.04.09.15.29.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Apr 2021 15:29:59 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 90BFB8009D6; Fri, 9 Apr 2021 17:29:58 -0500 (CDT) Date: Fri, 9 Apr 2021 17:29:58 -0500 From: Justin Pryzby To: Alvaro Herrera Cc: Robert Haas , Tom Lane , Zhihong Yu , pgsql-hackers@lists.postgresql.org, Yuzuko Subject: Re: pgsql: autovacuum: handle analyze for partitioned tables Message-ID: <20210409222958.GW6592@telsasoft.com> References: <20210409214508.GV6592@telsasoft.com> <20210409221659.GA28298@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210409221659.GA28298@alvherre.pgsql> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Apr 09, 2021 at 06:16:59PM -0400, Alvaro Herrera wrote: > On 2021-Apr-09, Justin Pryzby wrote: > > > One data point: we do DETACH/ATTACH tables during normal operation, before > > type-promoting ALTERs, to avoid worst-case disk use, and to avoid locking the > > table for a long time. It'd be undesirable (but maybe of no great consequence) > > to trigger an ALTER when we DETACH them, since we'll re-ATTACH it shortly > > afterwards. > > You mean to trigger an ANALYZE, not to trigger an ALTER, right? Oops, right. It's slightly undesirable for a DETACH to cause an ANALYZE. > I think I agree with Tomas: we should do it by default, and offer some > way to turn that off. I suppose a new reloptions, solely for > partitioned tables, would be the way to do it. > > > However, I think DROP should be handled ? > > DROP of a partition? ... I would think it should do the same as DETACH, > right? Inform that however many rows the partition had, are now changed > in ancestors. Yes, drop of an (attached) partition. The case for DROP is clear, since it was clearly meant to go away forever. The case for DETACH seems somewhat less clear. The current behavior of pg_dump/restore (since 33a53130a) is to CREATE+ATTACH, so there's an argument that if DROPping the partition counts towards the parent's analyze, then so should CREATE+ATTACH. -- Justin