Re: Flushing large data immediately in pqcomm
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: David Rowley <dgrowleyml@gmail.com>, Melih Mutlu <m.melihmutlu@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Ranier Vilela <ranier.vf@gmail.com>
Date: 2024-04-07T01:39:17Z
Lists: pgsql-hackers
Hi, On 2024-04-07 00:45:31 +0200, Jelte Fennema-Nio wrote: > On Sat, 6 Apr 2024 at 22:21, Andres Freund <andres@anarazel.de> wrote: > > The small regression for small results is still kinda visible, I haven't yet > > tested the patch downthread. > > Thanks a lot for the faster test script, I'm also impatient. I still > saw the small regression with David his patch. Here's a v6 where I > think it is now gone. I added inline to internal_put_bytes too. I > think that helped especially because for two calls to > internal_put_bytes len is a constant (1 and 4) that is smaller than > PqSendBufferSize. So for those calls the compiler can now statically > eliminate the new codepath because "len >= PqSendBufferSize" is known > to be false at compile time. Nice. > Also I incorporated all of Ranier his comments. Changing the global vars to size_t seems mildly bogus to me. All it's achieving is to use slightly more memory. It also just seems unrelated to the change. Greetings, Andres Freund
Commits
-
Avoid needless large memcpys in libpq socket writing
- c4ab7da60617 17.0 landed