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 1sbY3J-00HNBX-3d for pgsql-general@arkaria.postgresql.org; Wed, 07 Aug 2024 04:13:32 +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 1sbY3H-004JT1-EI for pgsql-general@arkaria.postgresql.org; Wed, 07 Aug 2024 04:13:31 +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 1sbY3H-004JSs-2x for pgsql-general@lists.postgresql.org; Wed, 07 Aug 2024 04:13:31 +0000 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sbY3A-003U0J-HI for pgsql-general@lists.postgresql.org; Wed, 07 Aug 2024 04:13:29 +0000 Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3684c05f7afso197154f8f.2 for ; Tue, 06 Aug 2024 21:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723004002; x=1723608802; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=yexBEW6BedN82t02jlxhGPJntzaQuOdmJiE+4fmuId0=; b=DhUVYOC1fYWC7pTKfQOYtpoFefc5ImiCCEVgxlUN41vzmI8wA3yhQMGOwnvAeO36ID W4qmJKP9NDNRPrv9jBOyMmXT0rrnBm0DZKExNPGgp7m+23YA9h/U5JKOHKfSEz4I0tMB 1HF/Mmg18PBAhQ1/E5Meg6bL6rWtcPXbrjzVJHXPlGV18iOqJWGpbfd/bxO5Br3wZFGo fmtI7W2kGypXt7RWjafAQwMdWKRv4HNNeD92RUcmGOyfhCNwBMF//udc110LS37LNJml Ef1/clEVt441Hr21jlGYkCoFLJhddtPHC/vOXvYrTGfO1W2zyAv/W5FFSqzeU4HDWQ2x Dehg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723004002; x=1723608802; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yexBEW6BedN82t02jlxhGPJntzaQuOdmJiE+4fmuId0=; b=fzn1UrODRUs9vNqUo1B2GyMsuvPoutPAcJl1/aAJmmmiH9WV109lqj4uait3J6e0I/ pc+/lTE5HqK/nx/nTNcjvALR1FRQ/BpKU8zhkwYAjc7iC3+dPKivVwQmJZ9FBUaa/gMp +pEpYCFwxm7JxGceq9vLn8VAMUzqYovC73nWdYMhwqUKU+Ae+nMs7Zj5TRmmi3hzY4eO 33C+LYyCdJeMHh4ixq06ffhaPr1nWFzMcmddNd5y+vNXR9pmUsj5vW4ZnG2eVMDop7uy 5vlrFoZnOzBxHBdidma0GRprs3DfcGKHci7IP71xxklhU2H4lIWCKrSqb0rOinn3b8H8 3UGQ== X-Gm-Message-State: AOJu0YwA2hvAYuRbC/xIHXC087UXzAqovQcV1IGUktxLosd9JDMtjbB0 5UsAEAsjCZtqZszYqfVvkr9ryieR4c9x5NGnwYXed4txFEkwJCn6i+6FZ76tsaDL3lP49iyRC8K fUC28g/t919BBhkEa+SQYgOLgN+6+g+1g X-Google-Smtp-Source: AGHT+IFSFWVw46H/zvomrGJL6BKD0qkEpzs1VcqTii6SwrvjRy2tyCehprz95WUO6YgpuKVY58crlgtCQc1eZw78aEU= X-Received: by 2002:a5d:47af:0:b0:35f:2929:8460 with SMTP id ffacd0b85a97d-36bbc0c82e6mr7464899f8f.3.1723004002239; Tue, 06 Aug 2024 21:13:22 -0700 (PDT) MIME-Version: 1.0 From: Michael Harris Date: Wed, 7 Aug 2024 14:13:10 +1000 Message-ID: Subject: ANALYZE on partitioned tables vs on individual partitions To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000800cfa061f10214a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000800cfa061f10214a Content-Type: text/plain; charset="UTF-8" Hello Experts, Our application has a database with a large number of partitioned tables used to store time series data. It is partitioned by time: new data is populated into the current partition, old partitions eventually get dropped, and the partitions in between are largely static. I had not realized until recently that the partitioned tables themselves are not analyzed by the autovacuum processes. I am now wondering if we should be manually analyzing those. The problem is they are quite enormous and take a long time to analyze - I tested one yesterday and it took ~30mins, and we have hundreds of them. It might not be practical to regularly analyze them. My questions are: 1. What is the consequence of not having good statistics on partitioned table level, if you do have good statistics on the partition level? 2. Which planning operations rely on partitioned table level statistics? My reason for asking is I'm trying to understand the tradeoff between the IO cost associated with frequently analyzing as opposed to possibly non-optimal plans being chosen. Thanks in advance, and sorry if this has all been covered before. I could not find anything definitive in the docs, and while I did find a few references by googling, none really explained the answers to those questions too well. Regards Mike --000000000000800cfa061f10214a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Experts,

Our application has a da= tabase with a large number of partitioned tables used to store time series = data.

It is partitioned by time: new data is popul= ated into the current partition, old partitions eventually get dropped, and= the partitions in between are largely static.

I h= ad not realized until recently that the partitioned=C2=A0tables themselves = are not analyzed by the autovacuum processes. I am now wondering if we shou= ld be manually analyzing those.

The problem is the= y are quite enormous=C2=A0and take a long time to analyze - I tested one ye= sterday=C2=A0and it took ~30mins, and we have hundreds=C2=A0of them. It mig= ht not be practical to regularly analyze them.

My = questions are:=C2=A0

=C2=A0 1. What is the consequ= ence of not having good statistics on partitioned table level, if you do ha= ve good statistics on the partition=C2=A0level?

= =C2=A0 2. Which planning operations rely on partitioned table level statist= ics?

My reason for asking is I'm trying to und= erstand the tradeoff between the IO cost associated with frequently analyzi= ng as opposed to possibly non-optimal plans being chosen.

Thanks in advance, and sorry if this has all been covered before. I= could not find anything definitive in the docs, and while I did find a few= references by googling, none really explained the answers to those questio= ns too well.

Regards
Mike

=
--000000000000800cfa061f10214a--