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 1pG6zF-00036C-RZ for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Jan 2023 23:27:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pG6zE-0004JT-J6 for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Jan 2023 23:27:56 +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 1pG6zE-0004JJ-8N for pgsql-hackers@lists.postgresql.org; Thu, 12 Jan 2023 23:27:56 +0000 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pG6z9-0006Kq-9b for pgsql-hackers@postgresql.org; Thu, 12 Jan 2023 23:27:55 +0000 Received: by mail-pf1-x432.google.com with SMTP id c9so14952139pfj.5 for ; Thu, 12 Jan 2023 15:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Ioc4p1zfp4PB4QggiebTZKMJ7i1HWDvoqRf7UV2TR6U=; b=L2wlpnzX7Y8OysFyIMhv1+EuVlQOnPe1R45S4Wf9rv1ecC076gU3tdWGW8rKHXgByh +4yXm72bcEYuxTE3DSyFHxWVfoBZHs2JDqoEIdjAZnF7+v5vP/06lO6Gj6uD7T3efOk5 VZWOickQIuPveOSAM0pIGlojuZ8k8r0vp85rVvZVR6lmYS5Dskjzavb1CGdQXluCTBI/ bSBmg8F3U9ymgWk1Hb8Tb1qcRWsOi9XsJ2dz1VLsFMMZ8pdFXwYCnDQTcjEH5jx9Kt2f UarH2vAKFHO+M4FMYu8fMRDgILrG1L7gz4FN+geBjXB+2B9nt5wqQPyUY3+FAkb758xI 16Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ioc4p1zfp4PB4QggiebTZKMJ7i1HWDvoqRf7UV2TR6U=; b=o/mZHSzA1Ky8Y0CQZ1KFBYh/fiRg6gWz2UT7pBEnwu/sCbG/o6mnK8npNPRd7K0OlX Y1DRJCGmKezlCQ6TdPDhDpeqP1uJbkQsy2ykGvkvnGcrSo70AxTcyXiU3j4qHJkIEn8p nQQCYzqNqOHK82xi4LgGj0+Fhktbo/OjTNBkb77Eyqe1AfcrNZSCFhjVgfHLuC30CyZ5 LvlO1tGWAJ7BHdBOUyi2/D8pHDGpMWBjkzM6NKrimMDaSIyuCS7Xm6dSGVI3ZD3OYDdF jqyO6MaRY5KjwDCX3b9dfdGpyWwCc9zJ68IU2MoRlgA/ZMG1ssbNHKJMQf4JpeNZDAe0 leYA== X-Gm-Message-State: AFqh2kq9onZcqnwVanivUJyGUAVtYUlz5vwd4qjTsvstwrx1hvjNEMLG /fF+TrebPY+TZHpnxv8L1dM= X-Google-Smtp-Source: AMrXdXuCTHOVxobgV/nyCGp0uzHdDG+X9SA8YQpw1hjANQpO40RNLRuvAhckKCRsbZOkC1BdhW4iuQ== X-Received: by 2002:aa7:9e4b:0:b0:582:407b:d90c with SMTP id z11-20020aa79e4b000000b00582407bd90cmr45269209pfq.28.1673566070041; Thu, 12 Jan 2023 15:27:50 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id b11-20020aa7950b000000b00581013fcbe1sm12397960pfp.159.2023.01.12.15.27.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Jan 2023 15:27:49 -0800 (PST) Date: Thu, 12 Jan 2023 15:27:47 -0800 From: Nathan Bossart To: Laurenz Albe Cc: Tomas Vondra , Justin Pryzby , Robert Haas , =?iso-8859-1?Q?=C1lvaro?= Herrera , yuzuko , pgsql-hackers@postgresql.org Subject: Re: document the need to analyze partitioned tables Message-ID: <20230112232747.GA2111950@nathanxps13> References: <20210913035409.GA10647@telsasoft.com> <20211008125822.GJ27491@telsasoft.com> <681e76ad-3a7b-ea3c-b6b0-55946239c49b@enterprisedb.com> <20220121180200.GM23027@telsasoft.com> <19c248d9-3687-9e0f-0b1a-2adad1de6fbe@enterprisedb.com> <20220315230011.GZ28503@telsasoft.com> <88903179-5ce2-3d4d-af43-7830372bdcb6@enterprisedb.com> <1fd81ddc7710a154834030133c6fea41e55c8efb.camel@cybertec.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1fd81ddc7710a154834030133c6fea41e55c8efb.camel@cybertec.at> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Oct 05, 2022 at 10:37:01AM +0200, Laurenz Albe wrote: > On Mon, 2022-03-28 at 15:05 +0200, Tomas Vondra wrote: >> I've pushed the last version, and backpatched it to 10 (not sure I'd >> call it a bugfix, but I certainly agree with Justin it's worth >> mentioning in the docs, even on older branches). > > I'd like to suggest an improvement to this. The current wording could > be read to mean that dead tuples won't get cleaned up in partitioned tables. Well, dead tuples won't get cleaned up in partitioned tables, as partitioned tables do not have storage. But I see what you mean. Readers might misinterpret this to mean that autovacuum will not process the partitions. There's a good definition of what the docs mean by "partitioned table" [0], but FWIW it took me some time before I consistently read "partitioned table" to mean "only the thing with relkind set to 'p'" and not "both the partitioned table and its partitions." So, while the current wording it technically correct, I think it'd be reasonable to expand it to help avoid confusion. Here is my take on the wording: Since all the data for a partitioned table is stored in its partitions, autovacuum does not process partitioned tables. Instead, autovacuum processes the individual partitions that are regular tables. This means that autovacuum only gathers statistics for the regular tables that serve as partitions and not for the partitioned tables. Since queries may rely on a partitioned table's statistics, you should collect statistics via the ANALYZE command when it is first populated, and again whenever the distribution of data in its partitions changes significantly. [0] https://www.postgresql.org/docs/devel/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE -- Nathan Bossart Amazon Web Services: https://aws.amazon.com