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-05 05:56:36
Message-ID: CAA4eK1LkpwvOcR6RVNHcEXocA5QK6o3btuwnBHT7-=AZUXPyjA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 5, 2025 at 9:50 AM Dmitry Koterov <dmitry(dot)koterov(at)gmail(dot)com> wrote:
>
> Only one index, the primary key.
>
> ChatGPT tells that temp files may be used, when bytea columns (or heavily toasted ones) are utilized, but it can’t explain, why. To me, it’s hard to believe that on the destination, the COPY stream receiver puts almost all of the received data to temp files, then waits for COPY to finish, and only then moves that temp files to data area, because of the large transaction or something. Would be cool to understand the reason.
>

One idea is that temporarily you drop the index before copy and see
what happens. Is it possible for you to share a self-contained test
case?

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-02-05 06:10:35 Re: Make COPY format extendable: Extract COPY TO format implementations
Previous Message Michael Paquier 2025-02-05 05:30:12 Re: Show WAL write and fsync stats in pg_stat_io