Re: Increased work_mem for "logical replication tablesync worker" only? - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Increased work_mem for "logical replication tablesync worker" only?
Date
Msg-id CAA4eK1L1oBxetevXa8y6ixC4L-Q7gG_WU+5L326yXQAoNg+Rrg@mail.gmail.com
Whole thread Raw
In response to Increased work_mem for "logical replication tablesync worker" only?  (Dmitry Koterov <dmitry.koterov@gmail.com>)
Responses Re: Increased work_mem for "logical replication tablesync worker" only?
List pgsql-hackers
On Sun, Feb 2, 2025 at 5:13 PM Dmitry Koterov <dmitry.koterov@gmail.com> wrote:
>
> Trying to monitor perf during the initial tablesync phase (COPY) right after CREATE SUBSCRIPTION. I noticed that the
sizeof 17/main/base/pgsql_tmp on the destination node grows (tens of gigabytes) as the COPY command (running internally
onthe publisher) progresses. Then in the end (when its "EXPLAIN SELECT 1 FROM tbl" on the destination shows the
approximatenumber of rows equals to the number of rows on the source node) it hangs for several minutes, and then
17/main/base/pgsql_tmpempties, and the subscription progresses. 
>
> It seems like if I increase work_mem to several GB, then the growth of 17/main/base/pgsql_tmp becomes less
significant.
>
> Questions:
>
> 1. Are there some diagnostics commands that would allow me to figure out what is in those tmp files? Why does the
subscribercreate those tmp files and not just write directly to the data files and WAL? (The table has 2 bytea columns,
i.e.it's TOASTed for sure.) 
>

We do write spill files (ending with '.spill') if the changes are
large. Can you please share the name of tmp files to avoid any
assumptions?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michel Pelletier
Date:
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
Next
From: Amit Kapila
Date:
Subject: Re: pg_rewind with --write-recovery-conf option doesn't write dbname to primary_conninfo value.