Re: [PATCH] Better Performance for PostgreSQL with large INSERTs

From: Andres Freund <andres(at)anarazel(dot)de>
To: Philipp Marek <philipp(at)marek(dot)priv(dot)at>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Better Performance for PostgreSQL with large INSERTs
Date: 2025-10-06 18:16:21
Message-ID: s2dvojvadijype6hlsl3oyladlvkd47thtrs65x6mkhzt4cagk@r3wpzxfu7tpw
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-10-06 18:20:15 Re: Should we update the random_page_cost default value?
Previous Message Jacob Champion 2025-10-06 18:05:54 Thoughts on a "global" client configuration?