Hi Robert, Robert Haas <robertmh...@gmail.com>, 29 Oca 2024 Pzt, 20:48 tarihinde şunu yazdı:
> > 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 thought about using writev() for not only pq_putmessage() but pq_putmessage_noblock() too. Currently, pq_putmessage_noblock() repallocs PqSendBuffer and copies input buffer, which can easily be larger than 8kB, into PqSendBuffer.I also discussed it with Thomas off-list. The thing is that I believe we would need secure_writev() with SSL/GSS cases handled properly. I'm just not sure if the effort would be worthwhile considering what we gain from it. > 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. You might be right. I'm not sure what the ideal threshold would be. > 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. > Sounds like it's difficult to come up with a heuristic that would work well enough for most cases. One thing with sending data instead of copying it if the buffer is empty is that initially the buffer is empty. I believe it will stay empty forever if we do not copy anything when the buffer is empty. We can maybe simply set the threshold to the buffer size/2 (4kB) and hope that will work better. Or copy the data only if it fits into the remaining space in the buffer. What do you think? An additional note while I mentioned pq_putmessage_noblock(), I've been testing sending input data immediately in pq_putmessage_noblock() without blocking and copy the data into PqSendBuffer only if the socket would block and cannot send it. Unfortunately, I don't have strong numbers to demonstrate any improvement in perf or timing yet. But I still like to know what would you think about it? Thanks, -- Melih Mutlu Microsoft