perf: replace BufferedOutputStream with unsynchronized PgBufferedOutputStream, allow configuring different Java and SO_SNDBUF buffer sizes

[vlsi]

This fixes two issues:

1. Java 21 uses ReentrantLock for BufferedOutputStream, however, we do not need synchronization as we synchronize at the level of QueryExecutor.execute

2. The default buffer size of 8192 was small for the modern connections

Fixes #3245

TODO:

• Benchmark large reads and writes
• Add extra tests for PgBufferedOutputStream
• Add new property maxSendBufferSize
• Move PGStream.sendInteger4 and PGStream.sendInteger2 to PgBufferedOutputStream so we do not need intermediate int[4] arrays for sending integers
• Move PGStream.sendStream to PgBufferedOutputStream so we can reuse PgBufferedOutputStream's buffer when reading data from the InputStream
• Refactor GSSOutputStream so it limits the produced messages (backend limits message size with 16KiB)
• Refactor GSSOutputStream so it avoids intermediate copies of the data when writing large array to GSS stream

Cancelled:

• Modify default value for send buffer size
• Modify receive buffer size
• Dynamically switch to a larger buffer size if we know there will be a big send request? As we send messages we do determine the message size in advance, so we can proactively increase the send buffer in case we know there will be many small writes (e.g. many binds)

/cc @plokhotnyuk

[plokhotnyuk]

The profile shows even better numbers than in my closed PR:

[vlsi]

Just wondering: do you have org/postgresql/core/v3/QueryExecutorImpl.sendParse on the profile?

[plokhotnyuk]

Just wondering: do you have org/postgresql/core/v3/QueryExecutorImpl.sendParse on the profile?

Yes, it is in the right corner of that profile with 56 samples:

[vlsi]

@plokhotnyuk , could you please try commenting this line

pgjdbc/pgjdbc/src/main/java/org/postgresql/jdbc/PgStatement.java

Line 869 in 450488c

flags |= QueryExecutor.QUERY_ONESHOT;

?

Would it alleviate QueryExecutorImpl.sendParse in your workload?

[plokhotnyuk]

@plokhotnyuk , could you please try commenting this line

pgjdbc/pgjdbc/src/main/java/org/postgresql/jdbc/PgStatement.java

Line 869 in 450488c

flags |= QueryExecutor.QUERY_ONESHOT;

?

Would it alleviate QueryExecutorImpl.sendParse in your workload?

I'm using PgPreparedStatement for the batch query and most CPU cycles of sendParse are burned in the isPrepareFor check:

[vlsi]

I noticed there's PGStream.streamBuffer byte[8192] which we use for sendStream(InputStream inStream).

It looks like we could add PgBufferedStream.write(InputStream) so we reuse and buffer from PgBufferedStream.
Any thoughts regarding that?

[plokhotnyuk]

Do we have any chance to re-use byte array buffers of PgBufferedStream to avoid redundant copying through int4, int2 buffers?

But before that need to find an ability to avoid boxing when checking type of serialisation for oids using generic hash maps.

[vlsi]

Do we have any chance to re-use byte array buffers of PgBufferedStream to avoid redundant copying through int4, int2 buffers?

This PR already fixes it for output, see PgBufferedOutputStream.writeInt2 and PgBufferedOutputStream.writeInt4.

But before that need to find an ability to avoid boxing when checking type of serialisation for oids using generic hash maps

That is on my list. Try using BitSet. I just did not want to mix many changes into a single PR.
The following improves useBinaryForSend for me:

@@ -62,6 +62,7 @@ import java.sql.SQLException;
 import java.sql.SQLWarning;
 import java.util.ArrayDeque;
 import java.util.ArrayList;
+import java.util.BitSet;
 import java.util.Collections;
 import java.util.Deque;
 import java.util.HashMap;
@@ -128,6 +129,7 @@ public class QueryExecutorImpl extends QueryExecutorBase {
    * Bit set that has a bit set for each oid which should be sent using binary format.
    */
   private final Set<Integer> useBinarySendForOids = new HashSet<>();
+  private final BitSet useBinarySendForOidsBs = new BitSet();

   /**
    * This is a fake query object so processResults can distinguish "ReadyForQuery" messages
@@ -3005,6 +3007,7 @@ public class QueryExecutorImpl extends QueryExecutorBase {
   public void addBinarySendOid(int oid) {
     synchronized (useBinarySendForOids) {
       useBinarySendForOids.add(oid);
+      useBinarySendForOidsBs.set(oid);
     }
   }

@@ -3012,6 +3015,7 @@ public class QueryExecutorImpl extends QueryExecutorBase {
   public void removeBinarySendOid(int oid) {
     synchronized (useBinarySendForOids) {
       useBinarySendForOids.remove(oid);
+      useBinarySendForOidsBs.set(oid, false);
     }
   }

@@ -3027,7 +3031,8 @@ public class QueryExecutorImpl extends QueryExecutorBase {
   @Override
   public boolean useBinaryForSend(int oid) {
     synchronized (useBinarySendForOids) {
-      return useBinarySendForOids.contains(oid);
+      return useBinarySendForOidsBs.get(oid);
     }
   }

@@ -3036,6 +3041,9 @@ public class QueryExecutorImpl extends QueryExecutorBase {
     synchronized (useBinarySendForOids) {
       useBinarySendForOids.clear();
       useBinarySendForOids.addAll(oids);
+      for (Integer oid : oids) {
+        useBinarySendForOidsBs.set(oid);
+      }
     }
   }

[vlsi]

The changes look good to me. It is still unclear if socket.getSendBufferSize() is a safe default.

[vlsi]

@plokhotnyuk , do you think you could benchmark 32KiB, 64KiB, 128KiB heap buffer sizes?
I wonder if increasing the heap buffer after 64KiB produces any improvements.

I am leaning towards adding sendMaxHeapBufferSize and receiveMaxHeapBufferSize and set them to 64KiB by default.

[plokhotnyuk]

@plokhotnyuk , do you think you could benchmark 32KiB, 64KiB, 128KiB heap buffer sizes? I wonder if increasing the heap buffer after 64KiB produces any improvements.

I am leaning towards adding sendMaxHeapBufferSize and receiveMaxHeapBufferSize and set them to 64KiB by default.

I think that having those options configurable even with setting them to 8KiB by default as for the current latest release would be an acceptable step, because bigger buffers will be required for batches mostly.

[vlsi]

I guess this is the only place where we can justify the buffer size :)

[plokhotnyuk]

@bokken Could you please review this PR to be merged and released in the next version?

[svendiedrichsen]

@vlsi Is there anyone else to review this? Would be great to have it in the next release.