Re: Flushing large data immediately in pqcomm
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Melih Mutlu <m.melihmutlu@gmail.com>,
Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Thomas Munro <thomas.munro@gmail.com>
Date: 2024-01-31T18:27:51Z
Lists: pgsql-hackers
On Wed, Jan 31, 2024 at 12:49 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote: > Testing a bunch of scenarios to find a good one sounds like a good > idea, which can probably give us a more optimal heuristic. But it also > sounds like a lot of work, and probably results in a lot of > discussion. That extra effort might mean that we're not going to > commit any change for PG17 (or even at all). If so, then I'd rather > have a modest improvement from my refinement of Melih's proposal, than > none at all. Personally, I don't think it's likely that anything will get committed here without someone doing more legwork than I've seen on the thread so far. I don't have any plan to pick up this patch anyway, but if I were thinking about it, I would abandon the idea unless I were prepared to go test a bunch of stuff myself. I agree with the core idea of this work, but not with the idea that the bar is as low as "if it can't lose relative to today, it's good enough." Of course, another committer may see it differently. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Avoid needless large memcpys in libpq socket writing
- c4ab7da60617 17.0 landed