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
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? |