@indiekitai/pg-dash 0.4.0 → 0.4.1

package/README.md

@@ -117,6 +117,13 @@ The Dashboard is there when you need it. But the real power is in the CLI, MCP,
 - `--health` flag adds health score comparison and unique issues per environment
 - `pg_dash_compare_env` MCP tool: ask your AI "what's different between local and staging?"
 
+### 🔧 Production Readiness Audit
+- **Unused indexes** — Find indexes with 0 scans since last stats reset; suggests safe `DROP INDEX CONCURRENTLY` SQL
+- **Table bloat** — Dead tuple ratio per table (≥10%); surfaces both `last_autovacuum` and `last_vacuum` timestamps
+- **Autovacuum health** — Classifies each table as `ok` / `stale` / `overdue` / `never`; shows autovacuum settings with units
+- **Lock monitoring** — Active lock-wait chains (who is blocking whom) + long-running queries >5s
+- **Config recommendations** — Audits `shared_buffers`, `work_mem`, `checkpoint_completion_target`, `random_page_cost`, `idle_in_transaction_session_timeout`, and 5 more settings with severity-tagged recommendations
+
 ### 🤖 MCP Server
 - 23 tools for AI agent integration
 - `pg-dash-mcp postgres://...` — works with Claude, Cursor, etc.

package/README.zh-CN.md

@@ -117,6 +117,13 @@ Dashboard 需要时可以用。但真正的核心能力在 CLI、MCP 和 CI。
 - `--health` 参数额外对比健康分和各环境独有的问题
 - `pg_dash_compare_env` MCP 工具：直接问 AI "本地和预发有什么差异？"
 
+### 🔧 生产就绪审计
+- **废弃索引检测** — 找出从未被使用（0 次扫描）的索引，自动生成带引号的 `DROP INDEX CONCURRENTLY` SQL
+- **表膨胀检测** — 统计每张表的 dead tuple 比例（≥10% 才展示），同时显示 `last_autovacuum` 和 `last_vacuum` 时间戳
+- **Autovacuum 健康** — 将每张表分类为 `ok` / `stale` / `overdue` / `never`，展示带单位的 autovacuum 配置
+- **锁监控** — 活跃的锁等待链（谁在阻塞谁）+ 超过 5 秒的长查询
+- **配置建议** — 审计 `shared_buffers`、`work_mem`、`checkpoint_completion_target`、`random_page_cost`、`idle_in_transaction_session_timeout` 等 10 项配置，给出带严重级别的调优建议
+
 ### 🤖 MCP Server
 - 23 个工具，支持 AI Agent 集成
 - `pg-dash-mcp postgres://...` —— 可配合 Claude、Cursor 等使用

package/dist/mcp.js

@@ -1933,7 +1933,18 @@ async function getUnusedIndexes(pool2) {
     pool2.query(`SELECT stats_reset FROM pg_stat_bgwriter`)
   ]);
   const statsReset = bgwriterResult.rows[0]?.stats_reset ? new Date(bgwriterResult.rows[0].stats_reset).toISOString() : null;
-  const indexes = indexResult.rows.map((row) => {
+  const filteredRows = indexResult.rows.filter((row) => {
+    const def = row.indexdef ?? "";
+    if (def.includes(" WHERE ")) return false;
+    const colStart = def.indexOf("(");
+    const colEnd = def.lastIndexOf(")");
+    if (colStart !== -1 && colEnd !== -1) {
+      const cols = def.slice(colStart + 1, colEnd);
+      if (cols.includes("(")) return false;
+    }
+    return true;
+  });
+  const indexes = filteredRows.map((row) => {
     const sizeBytes = parseInt(row.index_size_bytes, 10) || 0;
     const index = row.index_name;
     const table = row.table_name;
@@ -2236,7 +2247,7 @@ async function getConfigReport(pool2) {
     if (mb <= 4) {
       recommendations.push({
         setting: "work_mem",
-        currentValue: "4MB",
+        currentValue: `${mb % 1 === 0 ? mb : mb.toFixed(1)}MB`,
         recommendedValue: "16MB",
         reason: "work_mem of 4MB is conservative; consider 16MB\u201364MB for analytical queries (but multiply by max_connections for total)",
         severity: "info",
@@ -2325,7 +2336,7 @@ async function getConfigReport(pool2) {
     if (mb <= 64) {
       recommendations.push({
         setting: "maintenance_work_mem",
-        currentValue: "64MB",
+        currentValue: `${mb % 1 === 0 ? mb : mb.toFixed(1)}MB`,
         recommendedValue: "256MB",
         reason: "Consider 256MB for faster VACUUM and index builds",
         severity: "info",
@@ -2334,6 +2345,19 @@ async function getConfigReport(pool2) {
     }
   }
   const maxConnSetting = get("max_connections");
+  if (maxConnSetting !== null) {
+    const maxConn = parseInt(maxConnSetting, 10);
+    if (maxConn > 200) {
+      recommendations.push({
+        setting: "max_connections",
+        currentValue: String(maxConn),
+        recommendedValue: "100",
+        reason: `max_connections=${maxConn} is high. Each connection uses ~5\u201310MB RAM. Without a connection pooler (PgBouncer), this leads to memory pressure and context-switch overhead. Consider lowering to 100 and using a pooler.`,
+        severity: "warning",
+        docs: "https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-MAX-CONNECTIONS"
+      });
+    }
+  }
   const serverInfo = {
     maxConnections: maxConnSetting !== null ? parseInt(maxConnSetting, 10) : 0,
     sharedBuffers: formatMemSetting(sharedBuffersSetting, getUnit("shared_buffers")),