Message-ID: <64ccdcb7b15a17cbf610854e51cd8235c246cca8.camel@cybertec.at>
Subject: Re: Dealing with SeqScans when Time-based Partitions Cut Over
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Greg Sabino Mullane <htamfids@gmail.com>, Matthew Planchard
	 <msplanchard@gmail.com>
Cc: pgsql-general@postgresql.org
Date: Fri, 19 Dec 2025 18:42:34 +0100
In-Reply-To: <CAKAnmmL3_WPtWRrCy1t3zJOcDConYA__so4FZj_Bzzza-inJjw@mail.gmail.com>
References: <87bjjv1v96.fsf@gmail.com>
	 <CAKAnmmL3_WPtWRrCy1t3zJOcDConYA__so4FZj_Bzzza-inJjw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/64ccdcb7b15a17cbf610854e51cd8235c246cca8.camel%40cybertec.at>
Precedence: bulk

On Fri, 2025-12-19 at 09:49 -0500, Greg Sabino Mullane wrote:
> 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. Someth=
ing like this:
>=20
> * 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 co=
lumn- 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

I doubt that that is good advice.  For one, wrong statistics are not necess=
arily
better than no statistics.  Disabling autovacuum is dangerous - and re-enab=
ling
it would trigger another autovacuum, which would undo your efforts.
*Not* re-enabling autovacuum is not an option, unless you schedule explicit
VACUUM runs on the partition.

Yours,
Laurenz Albe