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 1sgHnD-000DRh-AX for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Aug 2024 05:52:31 +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 1sgHnA-009R81-F4 for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Aug 2024 05:52:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sgHnA-009R7t-4n for pgsql-hackers@lists.postgresql.org; Tue, 20 Aug 2024 05:52:28 +0000 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sgHn7-000Ypt-6w for pgsql-hackers@postgresql.org; Tue, 20 Aug 2024 05:52:28 +0000 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-3718ea278a8so544957f8f.3 for ; Mon, 19 Aug 2024 22:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724133144; x=1724737944; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=RunjK6uoI42kwfBnIugeSSI+HXoKyW2rJ4rmfwzpoTY=; b=bkDQoxFEhhhzdvKaEQq+XuD+SS4jPIyAlJASjdfT4MJeQEk9a+ELpEnfefDkhnGtRn c9GxwfPycU9krIkU626otAM0IcE4LFHblun2DAvBuSpKdKYUWo93DKAQGsRLYy1aHFT9 SWleFKwJ09LRWWSodNhXbfw2q6YRKwQV5q6gJIVvlKbr9W6kgT4O1vNCmSeB2Z4JszRa 0lti4lBaMNyDfeL26LYSq5iu36LW+W1U3NcYom8gaTeEaOVh1UMAddX7QD6Q62cql4oY pSt4KzWzDlcHPvtp+27zk5TbMvdPqbGslrhl9ylUBfWuHMLSnoZKg9tFKqS4tMTUu+71 7miQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724133144; x=1724737944; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=RunjK6uoI42kwfBnIugeSSI+HXoKyW2rJ4rmfwzpoTY=; b=efBLewXpZvJXCnZu5RHZsR2FmAjtORxD0yZBoSxmH5Fih+uRxd6VJM2j7oEyWsL8jq yHjmFjH7gwi6FOK9+Ag2/e87aZLcSEa7/wxyCvJFCcAWYtrqAht5IMj1sd6sEG3xgYWR 3NmrBQViQvXecoTTt9CsdtCeSSDZiCnc4kw5Ib6OQXoTOvbuSVrXCbxJGlL87223o8A5 cKvlVvAxfVI1exv1YF3wAQ2e9GYcnjD7BrpDY1JmERdHD8e1cowDg78Nwr5sxpCuyH7L m2lJqFcusYYI4HlLPpxtVhGwYQwZ68s4wj7wsjx1wAUwv/FtOQ6piEZY2KMcFjh5KuLX 8zOA== X-Gm-Message-State: AOJu0YzJgpAOloeOZ3jVHI8r6yetxnVc4QSPxXJ8YiWm5n4MWIrNvwKW yBVloOLY23TpaRZ2KaJNib5ByHaaxany0fYXXZCJcBlaVrVCYOZuStfvvENEri3Jwx9hHUVxM3V phrh5lkOG1GS1Cx93c92d4/olD1yJArLnD2o= X-Google-Smtp-Source: AGHT+IEd+IMQ4LyBDZApy+HZXXvbJYTSCOaxDwohTMlHd/pI2AtBH3ZlFIfM+r4dpeTqSTaOkpmtKoGkJzIHao5XZlo= X-Received: by 2002:a05:6000:1f8b:b0:368:5bf:82ab with SMTP id ffacd0b85a97d-371946adbd9mr5120910f8f.10.1724133144249; Mon, 19 Aug 2024 22:52:24 -0700 (PDT) MIME-Version: 1.0 From: Michael Harris Date: Tue, 20 Aug 2024 15:52:12 +1000 Message-ID: Subject: ANALYZE ONLY To: 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 Hello Postgres Hackers An application that I am developing uses Postgresql, and includes a fairly large number of partitioned tables which are used to store time series data. The tables are partitioned by time, and typically there is only one partition at a time - the current partition - that is actually being updated. Older partitions are available for query and eventually dropped. As per the documentation, partitioned tables are not analyzed by the autovacuum workers, although their partitions are. Statistics are needed on the partitioned table level for at least some query planning activities. The problem is that giving an ANALYZE command targeting a partitioned table causes it to update statistics for the partitioned table AND all the individual partitions. There is currently no option to prevent it from including the partitions. This is wasteful for our application: for one thing the autovacuum has already analyzed the individual partitions; for another most of the partitions will have had no changes, so they don't need to be analyzed repeatedly. I took some measurements when running ANALYZE on one of our tables. It took approx 4 minutes to analyze the partitioned table, then 29 minutes to analyze the partitions. We have hundreds of these tables, so the cost is very significant. For my use case at least it would be fantastic if we could add an ONLY option to ANALYZE, which would cause it to analyze the named table only and not descend into the partitions. I took a look at the source and it looks doable, but before launching into it I thought I would ask a few questions here. 1. Would such a feature be welcomed? Are there any traps I might not have thought of? 2. The existing ANALYZE command has the following structure: ANALYZE [ ( option [, ...] ) ] [ table_and_columns [, ...] ] It would be easiest to add ONLY as another option, but that doesn't look quite right to me - surely the ONLY should be attached to the table name? An alternative would be: ANALYZE [ ( option [, ...] ) ] [ONLY] [ table_and_columns [, ...] ] Any feedback or advice would be great. Regards Mike.