Re: Dealing with SeqScans when Time-based Partitions Cut Over

Поиск
Список
Период
Сортировка
Искать
От
Laurenz Albe
Тема
Re: Dealing with SeqScans when Time-based Partitions Cut Over
Дата
Msg-id
64ccdcb7b15a17cbf610854e51cd8235c246cca8.camel@cybertec.at
Ответ на
Список
Дерево обсуждения
Dealing with SeqScans when Time-based Partitions Cut Over Matthew Planchard <msplanchard@gmail.com>
Re: Dealing with SeqScans when Time-based Partitions Cut Over Laurenz Albe <laurenz.albe@cybertec.at>
Re: Dealing with SeqScans when Time-based Partitions Cut Over David Rowley <dgrowleyml@gmail.com>
Re: Dealing with SeqScans when Time-based Partitions Cut Over Greg Sabino Mullane <htamfids@gmail.com>
Re: Dealing with SeqScans when Time-based Partitions Cut Over Laurenz Albe <laurenz.albe@cybertec.at>
Re: Dealing with SeqScans when Time-based Partitions Cut Over Greg Sabino Mullane <htamfids@gmail.com>
Re: Dealing with SeqScans when Time-based Partitions Cut Over Ron Johnson <ronljohnsonjr@gmail.com>
Re: Dealing with SeqScans when Time-based Partitions Cut Over Matthew Planchard <msplanchard@gmail.com>
Re: Dealing with SeqScans when Time-based Partitions Cut Over David Rowley <dgrowleyml@gmail.com>
Re: Dealing with SeqScans when Time-based Partitions Cut Over Ron Johnson <ronljohnsonjr@gmail.com>
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. 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

I doubt that that is good advice.  For one, wrong statistics are not necessarily
better than no statistics.  Disabling autovacuum is dangerous - and re-enabling
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


В списке pgsql-general по дате отправления
От: Christoph Moench-Tegeder
Дата:
От: Igor Korot
Дата:
Сообщение: Fwd: PQexecPrepared() question
FAQ