On Mon, Jan 29, 2024 at 11:12 AM Heikki Linnakangas <hlinn...@iki.fi> wrote: > Agreed, that's silly.
+1. > If there's already some data in PqSendBuffer, I wonder if it would be > better to fill it up with data, flush it, and then send the rest of the > data directly. Instead of flushing the partial data first. I'm afraid > that you'll make a tiny call to secure_write(), followed by a large one, > then a tine one again, and so forth. Especially when socket_putmessage > itself writes the msgtype and len, which are tiny, before the payload. > > Perhaps we should invent a new pq_putmessage() function that would take > an input buffer with 5 bytes of space reserved before the payload. > pq_putmessage() could then fill in the msgtype and len bytes in the > input buffer and send that directly. (Not wedded to that particular API, > but something that would have the same effect) I share the concern; I'm not sure about the best solution. I wonder if it would be useful to have pq_putmessagev() in the style of writev() et al. Or maybe what we need is secure_writev(). I also wonder if the threshold for sending data directly should be smaller than the buffer size, and/or whether it should depend on the buffer being empty. If we have an 8kB buffer that currently has nothing in it, and somebody writes 2kB, I suspect it might be wrong to copy that into the buffer. If the same buffer had 5kB used and 3kB free, copying sounds a lot more likely to work out. The goal here is probably to condense sequences of short messages into a single transmission while sending long messages individually. I'm just not quite sure what heuristic would do that most effectively. -- Robert Haas EDB: http://www.enterprisedb.com