Message-ID: <e35ade27-17e0-4a51-a769-490291571d2f@gmail.com>
Date: Sat, 22 Feb 2025 09:37:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Unfortunate Nested Loop + Missing Autovacuum
To: Lincoln Swaine-Moore <lswainemoore@gmail.com>,
 pgsql-performance@lists.postgresql.org
References: 
 <CABcidkJT9FLu4hDT5VRKD+KGu0rLkJqhyqtAA42-P6QoVfh+kA@mail.gmail.com>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CABcidkJT9FLu4hDT5VRKD+KGu0rLkJqhyqtAA42-P6QoVfh+kA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/e35ade27-17e0-4a51-a769-490291571d2f%40gmail.com>
Precedence: bulk

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