Re: Flushing large data immediately in pqcomm
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Melih Mutlu <m.melihmutlu@gmail.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>,
Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Heikki Linnakangas <hlinnaka@iki.fi>, Thomas Munro <thomas.munro@gmail.com>
Date: 2024-03-21T00:45:06Z
Lists: pgsql-hackers
On Thu, 21 Mar 2024 at 13:24, Melih Mutlu <m.melihmutlu@gmail.com> wrote: > What if I do a simple comparison like PqSendStart == PqSendPointer instead of calling pq_is_send_pending() as Heikki suggested, then this check should not hurt that much. Right? Does that make sense? As I understand the code, there's no problem calling internal_flush_buffer() when the buffer is empty and I suspect that if we're sending a few buffers with "len > PqSendBufferSize" that it's just so unlikely that the buffer is empty that we should just do the function call and let internal_flush_buffer() handle doing nothing if the buffer really is empty. I think the chances of internal_flush_buffer() having to do exactly nothing here is less than 1 in 8192, so I just don't think the check is worthwhile. The reason I don't think the odds are exactly 1 in 8192 is because if we're sending a large number of bytes then it will be common that the buffer will contain exactly 5 bytes due to the previous flush and command prefix just having been added. It's worth testing both, however. I might be wrong. Performance is hard to predict. It would be good to see your test.sh script run with and without the PqSendStart == PqSendPointer condition. David
Commits
-
Avoid needless large memcpys in libpq socket writing
- c4ab7da60617 17.0 landed