Earlier quoted context omitted.
I’m not sure that’s it either. PostgreSQL has a feature — don’t remember what it’s called — where multiple readers can share a serial table scan. Suppose client A runs “select * from foo”, which has a thousand records. It can start streaming those results starting with row 1. Now suppose it’s on row 500 when client B runs the same query. Instead of starting over for B, it can start streaming results to B starting at…
That literally isn’t what pipelining is about in general nor is it relevant to this benchmark which is an insertion workload. The performance benefit observed literally is the ability to start executing the second request even though the ACK for the first one hasn’t fully ACK’ed. It’s also not true pipelining since you can’t send a follow up request that depends on the results of the previous incomplete request (eg l…
Re: Pipelining in psql (PostgreSQL 18)
#41Connection pooling has its own severe downsides in Postgres. Considering how limited we are by connection counts.