CLI database ops, as buttons. Local-only, no AI — psql operations turned into clicks.
テーブル名を押したら、中身が出るようになりました。1000 行ずつ、行数が「0」と嘘をつかない形で。
押した動機は、中身を見ることだった
これまでは押すと列の一覧が出ていました。マイグレーションを書いたのは自分なので、列の構成は知っています。
- 既定タブを Data に。 列と索引は 1 クリック先です
- タブが操作をまたいで保たれます。 パネルは htmx で丸ごと差し替わるので、列を 1 つ直すたびに先頭のタブへ弾き飛ばされていました
- 50 行で打ち切って 51 行目を見る手段が無かったのを、1000 行ずつのページ送りに（100 / 500 / 1000 / 5000 から選べます）
- グリッドだけがスクロールします。 列名とページ送りは画面に残ります
rows 1–1,000 of about 1,894,295 (estimated from statistics)
page 1 of about 1,895 ← Prev / Next → / [1,000 rows ▾]
並び順は主キー
順序を指定しない LIMIT/OFFSET は速いのですが、PostgreSQL は行の順序を約束しません。めくると同じ行が二度出たり、どこにも出ない行ができます ── ページャの体裁で嘘をつくことになります。
同梱の Airlines デモ（236 万行）で測りました。
| 先頭 | 最深部 | |
|---|---|---|
| ORDER BY 主キー | 7 ms | 878 ms |
| 順序なし | 0 ms | 50 ms（速いが正しくない） |
最深部で 878 ms なら払えます。主キーが無いテーブルでは並べようがないので、そう画面に書きます。
総数は count(*) を避けて統計の推定を使い、推定だと断ります。ただし**「次のページがあるか」は推定ではなく、返ってきた行数で決めます** ── 統計が古いと「次へ」が空振りし、それは総数が少しずれているより体験として悪いので。
「0 行」と「まだ数えていない」を分けました
同梱の Airlines デモは ticket_flights に 236 万行ありますが、サイドバーは 0 と出していました。
行数を pg_stat_user_tables.n_live_tup から取っていたのが原因です。あれはこのサーバが起動してから観測した書き込みの累積なので、ダンプから復元したデータベースでは、何かが書き込むまで永久に 0 のままです。プランナ統計には最初から正しい値が入っていました。
reltuples を見るようにし、あわせて **ANALYZE されていないテーブルは 0 ではなく「不明」**と出すようにしました。この規則は破壊ボタンの手前には既にあったのに（0 と書くと「空だから消していい」に読めるため）、一覧だけが 0 と言っていたので、同じ製品の中で言うことが違っていたことになります。
ワークスペースの合計も、不明を 0 として足すのをやめました。知らないものを足すと、合計だけがそれらしい顔で嘘をつきます。
数えた数は 3 桁で区切ります
2,360,335 です。6 桁を超えると、区切りの無い数字は読むのではなく数えることになります。
ただしデータベースから読んだ値は、来たまま出します。 bigint の 1048576 は 1048576 のままです。ここを整形するのは、v1.7.0 でやめたばかりの「画面がデータを書き換える」ことそのものになります。どちらの数かで扱いが逆です。
そのほか
- ナビの右側に、いま開いているテーブル名を出すようにしました。
#detailは htmx で丸ごと入れ替わり、ブラウザの履歴にも残らないので、現在地がタイトルにしか無い状態でした - 見出しの下の「N 列 · 最大 1000 行をプレビュー」を消し、件数はタブのラベルへ移しました（
列 4/インデックス 3）。ページャが正確に言うようになって重複していたためで、同じことを 2 か所で言うと、いつか片方が古くなります
docker compose pull && docker compose up詳細は CHANGELOG。