Why does backend send buffer size hardcoded at 8KB?

Why backend send buffer use exactly 8KB? 
(https://github.com/postgres/postgres/blob/249d64999615802752940e017ee5166e726bc7cd/src/backend/libpq/pqcomm.c#L134) 


I had this question when I try to measure the speed of reading data. The 
bottleneck was a read syscall. With strace I found that in most cases 
read returns 8192 bytes (https://pastebin.com/LU10BdBJ). With tcpdump we 
can confirm, that network packets have size 8192 
(https://pastebin.com/FD8abbiA)

So, with well-tuned networking stack, the limit is 8KB. The reason is 
the hardcoded size of Postgres write buffer.

I found discussion, where Tom Lane says that the reason of this limit is 
the size of pipe buffers in Unix machines: 
https://www.postgresql.org/message-id/9426.1388761242%40sss.pgh.pa.us

 > Traditionally, at least, that was the size of pipe buffers in Unix 
machines, so in principle this is the most optimal chunk size for 
sending data across a Unix socket.  I have no idea though if that's 
still true in kernels in common use today. For TCP communication it 
might be marginally better to find out the MTU size and use that; but 
it's unclear that it's worth the trouble, or indeed that we can
know the end-to-end MTU size with any reliability.

Does it make sense to make this parameter configurable?

-- 
Artemiy Ryabinkov
getlag(at)ya(dot)ru