Re: Increased work_mem for "logical replication tablesync worker" only?

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Dmitry Koterov <dmitry(dot)koterov(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Increased work_mem for "logical replication tablesync worker" only?
Date: 2025-02-04 06:32:51
Message-ID: CAA4eK1Lqjrt1s2Dm+yqO4dzwNUA7ixRCLFYF5Rtk_+dj4q-E8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 3, 2025 at 6:19 PM Dmitry Koterov <dmitry(dot)koterov(at)gmail(dot)com> wrote:
>
> What's also suspicious is that on the destination node, after copying finishes,
>
> # explain select 1 from mytable;
> Seq Scan on mytable (cost=0.00..6821514.12 rows=250410012 width=4)
>
> # SELECT relname, n_live_tup FROM pg_stat_user_tables WHERE relname = 'mytable';
> relname | estimated_rows
> -------------+----------------
> mytable | 150342468
>
> Notice the discrepancy between how many rows EXPLAIN thinks there is in the table, and how many rows pg_stat_user_tables thinks about it (250M vs. 150M).
>

Is it possible that analyze has not yet run on the table on
subscribers? Can you try running the Analyze command on the subscriber
before trying the above two statements?

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2025-02-04 06:35:40 Re: Avoid updating inactive_since for invalid replication slots
Previous Message Amit Kapila 2025-02-04 06:31:13 Re: Increased work_mem for "logical replication tablesync worker" only?