Thanks Jeff for the response--I did end up just analyzing the tables
manually, as a stopgap. Resource consumption was a non-issue as you
predicted (and plan was corrected, though estimates were still slightly
awkward).
With respect to the blocking of the autovacuum/analyze: no it shouldn't be
the
On 23/2/2025 23:49, Lincoln Swaine-Moore wrote:
Thanks for the reply! I tried the analysis on our much shorter staging
table and it did change the plan. I haven’t tried it on the production
ones because my understanding is that the autovacuum process is gentler
with resource consumption and I d
On Sun, Feb 23, 2025 at 5:49 PM Lincoln Swaine-Moore
wrote:
> Thanks for the reply! I tried the analysis on our much shorter staging
> table and it did change the plan. I haven’t tried it on the production ones
> because my understanding is that the autovacuum process is gentler with
> resource c
Thanks for the reply! I tried the analysis on our much shorter staging
table and it did change the plan. I haven’t tried it on the production ones
because my understanding is that the autovacuum process is gentler with
resource consumption and I didn’t want to gum things up in the meantime.
But tha
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
Hi all--
Writing in with a two-parter performance issue.
I've got two tables roughly shaped like this:
Table "public.rawdata"
Column |Type | Collation | Nullable
| Default
--
