Hi Jakub,
Can you please how have you verified it is giving you that some perf.
increase?
...
where insert.sql was:
echo "CREATE TEMPORARY TABLE IF NOT EXISTS file_storage (data
BYTEA STORAGE EXTERNAL) ON COMMIT PRESERVE ROWS;" > insert.sql
echo "INSERT INTO file_storage(data) VALUES ('" >> insert.sql
perl -e 'print "A"x(1024*1024);' >> insert.sql # 1MB
echo "');" >> insert.sql
This data might be too easily compressed.
In production we upload files (PDFs), for benchmarking
we generated random data.
This might make a big difference on the network side
if you're using TLS with compression, for example.
Some description of the env I had:
- tuned TCP rmem/wmem and set congestion to BBR (to eliminate TCP as
being a bottlneck)
Well, if your tcp_rmem buffers are bigger than the data you upload,
that might also soften the impact of the patch.
- low RTT (same AWS zone), max 25Gbps total, max 9.6 Gbps single stream
TCP
That might also be a big difference,
we had a few msec inbetween client and server.
- as TOAST pglz compression way taking most of CPU in my case , I've
changed it to lz4 also didn't help a lot, so I've changed it to avoid
*any* compression
We had no compression set on the table
- switched to temporary table to avoid I/O as much as possible,
wal_level=minimal too
We didn't use a temporary table.
If you think that's helpful,
I can try to dig out what we used to benchmark
the receive buffer size impact.
Regards,
Phil
