Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Pipeline mode for Pool

オープン
#3,738 コメント 3 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
javascript, postgresql
領域
backend, databases

調査の方向性

Pool の設定と pool.query() のエントリーポイントから始め、Client がどのように取得、使用、返却されるかを追跡します。既存の Client パイプラインの動作を、要求されている idle、busy、full の接続グループと比較します。完了の条件は、パイプラインが有効なプールが maxPipeline までビジーな接続を再利用でき、カーソルはパイプライン処理されないことです。

索引モデルが issue の本文から書いたものです。

説明

feature request

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
主要言語
JavaScript
スター
13.2k
フォーク
1.4k
平均マージ
6日 15時間
マージ済み PR(30日)
6

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

brianc/node-postgres のほかの issue

brianc/node-postgres の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。