Re: Flushing large data immediately in pqcomm
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Melih Mutlu <m.melihmutlu@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Andres Freund <andres@anarazel.de>, Heikki Linnakangas <hlinnaka@iki.fi>, Thomas Munro <thomas.munro@gmail.com>, Jelte Fennema-Nio <postgres@jeltef.nl>
Date: 2024-03-27T15:54:22Z
Lists: pgsql-hackers
On Wed, Mar 27, 2024 at 7:39 AM David Rowley <dgrowleyml@gmail.com> wrote: > Robert, I understand you'd like a bit more from this patch. I'm > wondering if you planning on blocking another committer from going > ahead with this? Or if you have a reason why the current state of the > patch is not a meaningful enough improvement that would justify > possibly not getting any improvements in this area for PG17? So, I think that the first version of the patch, when it got a big chunk of data, would just flush whatever was already in the buffer and then send the rest without copying. The current version, as I understand it, only does that if the buffer is empty; otherwise, it copies data as much data as it can into the partially-filled buffer. I think that change addresses most of my concern about the approach; the old way could, I believe, lead to an increased total number of flushes with the right usage pattern, but I don't believe that's possible with the revised approach. I do kind of wonder whether there is some more fine-tuning of the approach that would improve things further, but I realize that we have very limited time to figure this out, and there's no sense letting the perfect be the enemy of the good. So in short... no, I don't have big concerns at this point. Melih's latest benchmarks look fairly promising to me, too. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Avoid needless large memcpys in libpq socket writing
- c4ab7da60617 17.0 landed