Re: [PATCH] Better Performance for PostgreSQL with large INSERTs - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PATCH] Better Performance for PostgreSQL with large INSERTs
Date
Msg-id s2dvojvadijype6hlsl3oyladlvkd47thtrs65x6mkhzt4cagk@r3wpzxfu7tpw
Whole thread Raw
In response to Re: [PATCH] Better Performance for PostgreSQL with large INSERTs  (Philipp Marek <philipp@marek.priv.at>)
List pgsql-hackers
Hi,

On 2025-09-30 10:42:00 +0200, Philipp Marek wrote:
> Here's the patch again, this time with a 128kB buffer size.
> 
> This gives us nearly the same gains (~7%) for the blob INSERTs,
> and the additional memory usage (120kB) shouldn't really matter,
> with "temp_buffer"s 8MB and "work_mem" 4MB defaults.
> 
> Making it configurable would give a much more complex patch --
> so I suggest just using this fixed size.

Have you tried to verify that this doesn't cause performance regressions in
other workloads? pq_recvbuf() has this code:

    if (PqRecvPointer > 0)
    {
        if (PqRecvLength > PqRecvPointer)
        {
            /* still some unread data, left-justify it in the buffer */
            memmove(PqRecvBuffer, PqRecvBuffer + PqRecvPointer,
                    PqRecvLength - PqRecvPointer);
            PqRecvLength -= PqRecvPointer;
            PqRecvPointer = 0;
        }
        else
            PqRecvLength = PqRecvPointer = 0;
    }

I do seem to recall that just increasing the buffer size substantially lead to
more time being spent inside that memmove() (likely due to exceeding L1/L2).

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Thoughts on a "global" client configuration?
Next
From: Tomas Vondra
Date:
Subject: Re: Should we update the random_page_cost default value?