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.96) (envelope-from ) id 1vWboF-005kpT-1T for pgsql-general@arkaria.postgresql.org; Fri, 19 Dec 2025 14:50:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vWboE-0081tO-0c for pgsql-general@arkaria.postgresql.org; Fri, 19 Dec 2025 14:50:22 +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.96) (envelope-from ) id 1vWboD-0081tF-2n for pgsql-general@lists.postgresql.org; Fri, 19 Dec 2025 14:50:22 +0000 Received: from mail-ot1-x32c.google.com ([2607:f8b0:4864:20::32c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vWboD-001WHV-0x for pgsql-general@postgresql.org; Fri, 19 Dec 2025 14:50:21 +0000 Received: by mail-ot1-x32c.google.com with SMTP id 46e09a7af769-7c75dd36b1bso1334141a34.2 for ; Fri, 19 Dec 2025 06:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766155820; x=1766760620; 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=yZmsyJbXqyw0xPAEfRZq0F/RlKCMHI63xb641BQ8/As=; b=amhn/fH0nn+J59s3yxlih8tPbpyK/UctLW49/wl4+IsXN7gg3YK2Oi/swAVqp2pr7i +WErndozM3OcpVC4ps9YN6T37x83x2aEUwMNC94VZB7ZRSmixsnDj9OP9iQ2TWV80E05 cMk3wXuennkQUjH0x/e85ONFzwZLPH2TtsP3LVZAr5QyT4v3A/6G6RC91raLdn0qrO06 xqXPtW8Y8PGOE9S3pU0QJDDJzIJ/62Sf/39shX4N3F9alVGbM/kHVjtrPw2Yhu6UgDD7 Xm3pc9XievRi2eLvBS4KFr1gQcPlNyphTyTUE2iW0TTMOkpmNj0TZEZN728KDG7mjgET lRyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766155820; x=1766760620; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yZmsyJbXqyw0xPAEfRZq0F/RlKCMHI63xb641BQ8/As=; b=ByE+P+yYf4Thg764aCfYSI/z4Xwiywu5BQO4Zd0IOY9EapQr0672/fHrSdrmPg3CEE nfNpoLcYPPDCqxlk6RKpPila/28XH+qGdz7PNFIe1uOYEsQcw3psyFWBOVxte6WgNU6w qP5iEr9uwJytuA1MS5P6mjgJrrTf7w/mwFGatYB+zq0cv5avM8jLELeOXMkapoXDH6c4 RZhyVB+8siZRvj2EHvaMe4r7Zz50JGo0zjHKtvbgg2SeW397uhNnm289S3cNEL6gvpA7 XvLGy0aN+yNSVPogo0o6+4MaZIBNlRL/zTmwTlIqebtZYpSbzXbb8Tde6x7VA72gwMV1 Uq6g== X-Gm-Message-State: AOJu0YyzwfVohwHdhTkDaixLqGMHWY8iOUS3Sk+KyE5V93lc3YFTxWck HCQGdJbAgpSiPwjY7ELPvP5pA9HyrG891DMTdmMIIn/zVyVW4cRD/jWf1rSw7TiSkOlM6PkN+bg LmShda4M+1Ibx5maAWxswfbDU6w8uQxhhoxO/ X-Gm-Gg: AY/fxX7Wa8iAs37dMw/naHr8hliZfJrTt9SchU2Kgn/bYcvcFb8aOO/aLPQw1IgRQg9 RirQHIHHR1C3yAuOmEpweUsNxGbiAW+kc5JxZq4JEQiHWHq1AtxPu/4Hmakpbe2n7rte/71brXJ NF7RBkB5TcfnplMzeBuAy1jJ+xgDx0w0WF49lOds0oUlm6ZN3KAaExGfJeN871Yj7+oXE/7kRWK jiMHtyegXnW8Ljzvu/G0zlZMumsAIOaYtF0O+mlcRGCZqcgTPKT0VP0pv/ve+r5bpxI/nsPCH1K Wl3uLx48b7oHLSFoZJtI88iN2YQ= X-Google-Smtp-Source: AGHT+IF3dNoC2q44N8eVibo+7tIuFIgqEbsr+h0nTkOF0MNHp47JTF02c4ra712D21DuE9++566dJd9sn6vubOvIXkE= X-Received: by 2002:a05:6820:1691:b0:659:9a49:9044 with SMTP id 006d021491bc7-65d0e94d376mr1292545eaf.15.1766155819921; Fri, 19 Dec 2025 06:50:19 -0800 (PST) MIME-Version: 1.0 References: <87bjjv1v96.fsf@gmail.com> In-Reply-To: <87bjjv1v96.fsf@gmail.com> From: Greg Sabino Mullane Date: Fri, 19 Dec 2025 09:49:48 -0500 X-Gm-Features: AQt7F2oufG2hdfA1OiutwJelgjwCpFZOGPICr_d-9C-S9AzlWJQDgLudfBZCn6c Message-ID: Subject: Re: Dealing with SeqScans when Time-based Partitions Cut Over To: Matthew Planchard Cc: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="00000000000043b58406464f3263" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000043b58406464f3263 Content-Type: text/plain; charset="UTF-8" If this is still an issue after you check David's theory about premature analyzing, another approach is to pre-populate and pre-analyze future tables. Something like this: * disable autovac on the future table * detach the table from the main partition * insert a few hundred thousand rows into it, then run analyze on it * can pull rows from a current table, or just use random data on a key column- whatever is enough to generate "good" stats * delete the rows - the stats will remain * reattach the table * enable autovac if you like; I would not Cheers, Greg -- Crunchy Data - https://www.crunchydata.com Enterprise Postgres Software Products & Tech Support --00000000000043b58406464f3263 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If this is still an issue after you = check David's theory about premature analyzing, another approach is to = pre-populate and pre-analyze future tables. Something like this:
=
* disable autovac on the future table
=
* detach the table from the main partition
* insert a few hu= ndred thousand rows into it, then run analyze on it
* can pull ro= ws from a current table, or just use random data on a key column- whatever = is enough to generate "good" stats
* delete the rows - = the stats will remain
* reattach the table
* enable aut= ovac if you like; I would not


Cheers,
<= div>Greg

--
<= div>
--00000000000043b58406464f3263--