Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sgNNE-001LoA-QC for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Aug 2024 11:50:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sgNNC-00Ffi2-My for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Aug 2024 11:50:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sgNNC-00Ffhu-DH for pgsql-hackers@lists.postgresql.org; Tue, 20 Aug 2024 11:50:02 +0000 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sgNN6-000Yvc-Gr for pgsql-hackers@postgresql.org; Tue, 20 Aug 2024 11:50:01 +0000 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2f3f0bdbcd9so3864961fa.1 for ; Tue, 20 Aug 2024 04:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724154594; x=1724759394; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uUjr/9D+ykVveF4L5kxUt7zE+d1X9jLNykCt/WxqRZ4=; b=aRIu//g2J0IAdW8vcAzIfh/EJQmfBHrC/ID4L1CvhCYngOCR0OJlTDqZX0SNojUfIR NNT8JSG86p04Eku/nDdoxoDU94yrf6yHJdX0u11HrPCszXDcSXi/LDstCBjvjRuo0gc3 VsRL0W/9xWV3ut4SQ9UPJI5AJ9U0oe666MvwSH7efJgJAC/u53hQFOBV2gZ3rfxwuihb iJIIALQVIaREDDH0YxA5mKehuVFeJt7T5oU9MnRTLUhZhEi/aTPlPDsq/xjtHUjJmBn1 0ruXwh10HEJjyyemWDDv8Vbvsdabf5nToLqjH6+paPqW0j1A30UUOgcaQC3XpYLi2ikC Utqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724154594; x=1724759394; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uUjr/9D+ykVveF4L5kxUt7zE+d1X9jLNykCt/WxqRZ4=; b=bCSeJih/Q8BGSws73M5DhhsjGdjI82w0Xjzo8u00ljgt0JvNAh4ffR2JfPuKzNrSr8 /TdBNNbjsQ4O8h+qFEUBbWcDYsz9Mpa7mp6mzvD6pMmB+m/SA/ui7Tjfem66Rdpk6SAE CAx08qAoO/Us3/5AUhPRC8oNiU2DEgOH+9oc9B7CEQFJd9lX67Uu814uSOGUn6px1swB fDRMs3I2QgSznGzR5Fzk8YZchbycH6pZhcIk3JvNSkmpcEG54Z9n4GQ650cMIEgm0lMq Mt3zET1tI0DH8YIrhOuG/+Hk6dCKlPtQigvSIHYkDxvosb1MlNxKCaHz6T0CWf058vVg wo5Q== X-Forwarded-Encrypted: i=1; AJvYcCWns1i+ZUhcbV03E0z2gUqQz8OTyULl5URenI5PM9kxSSOJW+I17qVg2BxgJt7qypqMbYbNNUXYtDhTbAbe6xM2n4piMMP5ujArH1RU X-Gm-Message-State: AOJu0YzgX0IeJViPzPub5C/pKpyAvacJcrwwjOttc7iHgdd0z/ZClg9W g0FLFu1ocSwIQ1UVr8OYEfdU3IQTC9mdItCuJJvkfNzd4l0NAMwoJEKMgZy3kQ9nlwg3VB0Dal8 xuvKMeLfBwLzhaBR1klx2NNdOxP8= X-Google-Smtp-Source: AGHT+IEkcUCACGFq24adU8ZjBr95SHWOa6EMvJCAeYnprdNrtIwUM+VDm7YrnaO8jj+ikFXmWEM7CxPPbcypSHyBYvg= X-Received: by 2002:a05:6512:3d0f:b0:530:db85:e02a with SMTP id 2adb3069b0e04-5334079430dmr1361939e87.22.1724154593869; Tue, 20 Aug 2024 04:49:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Rowley Date: Tue, 20 Aug 2024 23:49:41 +1200 Message-ID: Subject: Re: ANALYZE ONLY To: Ilia Evdokimov Cc: Jelte Fennema-Nio , Michael Harris , PostgreSQL-development Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 20 Aug 2024 at 23:25, Ilia Evdokimov wrote: > Your proposal is indeed interesting, but I have a question: can't your issue be resolved by properly configuring autovacuum instead of developing a new feature for ANALYZE? Basically, no. There's a "tip" in [1] which provides information on the limitation, namely: "The autovacuum daemon does not issue ANALYZE commands for partitioned tables. Inheritance parents will only be analyzed if the parent itself is changed - changes to child tables do not trigger autoanalyze on the parent table. If your queries require statistics on parent tables for proper planning, it is necessary to periodically run a manual ANALYZE on those tables to keep the statistics up to date." There is also some discussion about removing the limitation in [2]. While I agree that it would be nice to have autovacuum handle this, it's not clear how exactly it would work. Additionally, if we had that, it would still be useful if the ANALYZE command could be instructed to just gather statistics for the partitioned table only. David [1] https://www.postgresql.org/docs/devel/routine-vacuuming.html#VACUUM-FOR-STATISTICS [2] https://www.postgresql.org/message-id/flat/CAKkQ508_PwVgwJyBY%3D0Lmkz90j8CmWNPUxgHvCUwGhMrouz6UA%40mail.gmail.com