pipeline: true works on a Client but a Pool cannot use it. pool.query() checks a client out, runs one query on it and gives it back only when the result arrives, so there is never a second query on that connection to pipeline with. Passing pipeline: true to the Pool config changes nothing today.
postgres.js already does this automatically. It keeps the connections in three groups:
- idle
- busy but still accepting
- full
when nothing is idle it sends the query on a busy one.
It limits itself with a depth cap (max_pipeline, default 100), with the socket backpressure, and it refuses to pipeline cursors.
The same is possible here and the public API almost does not change:
const pool = new Pool({ max: 10, pipeline: true, maxPipeline: 100 })
await pool.query('SELECT $1::int', [1]) // same call, can go on a connection already working
pipeline: trueworks on aClientbut aPoolcannot use it.pool.query()checks a client out, runs one query on it and gives it back only when the result arrives, so there is never a second query on that connection to pipeline with. Passingpipeline: trueto thePoolconfig changes nothing today.postgres.js already does this automatically. It keeps the connections in three groups:
when nothing is idle it sends the query on a busy one.
It limits itself with a depth cap (
max_pipeline, default 100), with the socket backpressure, and it refuses to pipeline cursors.The same is possible here and the public API almost does not change: