| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Lincoln Swaine-Moore <lswainemoore(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Unfortunate Nested Loop + Missing Autovacuum |
| Date: | 2025-02-22 08:37:40 |
| Message-ID: | e35ade27-17e0-4a51-a769-490291571d2f@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 22/2/2025 00:46, Lincoln Swaine-Moore wrote:
> So, obviously there's a statistics problem, which led me to realize that
> actually these tables have *never* been autovacuumed/analyzed according
> to pg_stat_user_tables.
> I'm using a managed database which makes it a little tricky to debug,
> but all my settings
> (autovacuum/autovacuum_vacuum_threshold/autovacuum_analyze_threshold/
> autovacuum_vacuum_insert_threshold) are default,
> and I can see that other tables have been vacuumed recently.
I know a couple of reports related to this kind of behaviour and
different solutions to resolve it. But first, if you execute the ANALYZE
command on these problematic tables, does it fix your issue? May you
live with manual vacuum analysis each time after batch insertion?
If not, may you provide a synthetic reproduction of the case?
--
regards, Andrei Lepikhov
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Lincoln Swaine-Moore | 2025-02-21 23:46:15 | Unfortunate Nested Loop + Missing Autovacuum |