docs(deploy): 补充 PostgreSQL 初始规格

README.md

@@ -95,7 +95,7 @@ EasyAI 应用 Pod 当前资源规格如下，CPU 和内存均为单个 Pod 的
 | MongoDB | 云服务高可用版，或 3 个数据节点的副本集 | Atlas `M30` 参考值为 `2 vCPU / 8GB`；自建环境以压测为准 | 无存量数据时每节点可从 `50Gi` SSD 开始压测；已有数据按下方公式计算 | `M30` 的 `3000/s` 和 `20–50GB` 是 Atlas 近似集群负载，不是自建单节点性能承诺 |
 | Redis | 云服务高可用版，或主节点 + 2 个副本并配套 Sentinel | `2 vCPU / 4Gi` | 每节点 `20Gi` SSD，建议 `maxmemory` 初始设为 `2Gi` | 规划参考；必须支持多个逻辑 DB 和 `SELECT`，当前不支持 Redis Cluster 模式 |
 | RabbitMQ | 3 节点集群，持久化业务队列使用 quorum queue | 请求 `1 vCPU / 2Gi`，上限 `2 vCPU / 2Gi` | 每节点 `50Gi` RWO SSD，总计 `150Gi` | 当前自建模板实际值；高吞吐或大消息场景需压测后增加内存和磁盘 |
-| PostgreSQL + pgvector | 云服务高可用版，或主库 + 备库并配置经过验证的自动故障切换、隔离机制和统一访问端点 | 按实际 SQL、并发客户端和向量检索压测确定 | 无存量数据时每节点可从 `50Gi` SSD 开始压测；已有数据按下方公式计算 | PostgreSQL 官方没有统一的 TPS 与硬件换算；本地 `1 CPU / 1Gi` 仅为功能验证上限，不是生产基线 |
+| PostgreSQL + pgvector | 云服务高可用版，或主库 + 备库并配置经过验证的自动故障切换、隔离机制和统一访问端点 | 项目初始参考 `2 vCPU / 8Gi` | 无存量数据时每节点可从 `50Gi` SSD 开始压测；已有数据按下方公式计算 | 按实际 SQL、并发客户端、向量规模和检索压测调整；本地 `1 CPU / 1Gi` 仅为功能验证上限 |
 | RWX 共享存储 | 支持高可用和在线扩容的 RWX 存储 | 由存储服务决定 | 初始总容量 `100Gi` | 当前生产 PVC 实际值；不包含独立备份空间 |
 | OSS/S3 对象存储 | 云厂商托管对象存储 | 由对象存储服务决定 | 按量使用，无需预分配固定容量 | 可选；建议配置生命周期和历史文件清理策略 |
 
@@ -132,7 +132,7 @@ MongoDB 单节点数据盘
 
 ##### PostgreSQL 与 pgvector 规格计算依据
 
-PostgreSQL 官方没有提供“多少 QPS/TPS 对应多少 CPU 和内存”的通用硬件表。查询复杂度、索引命中率、并发事务、向量维度、HNSW/IVFFlat 选择、召回率目标和存储延迟都会显著改变结果。当前仓库只有本地功能验证数据，没有可支撑固定生产 CPU/内存数字的项目压测结果，因此生产规格必须通过实际负载确定。
+PostgreSQL 官方没有提供“多少 QPS/TPS 对应多少 CPU 和内存”的通用硬件表。查询复杂度、索引命中率、并发事务、向量维度、HNSW/IVFFlat 选择、召回率目标和存储延迟都会显著改变结果。为了给首次生产部署提供可执行的压测起点，本项目采用单节点 `2 vCPU / 8Gi`：按照 [PostgreSQL 18 Resource Consumption](https://www.postgresql.org/docs/18/runtime-config-resource.html) 的建议，将 `shared_buffers` 从总内存的 `25%` 起步时约为 `2Gi`，其余内存用于操作系统文件缓存、并发 `work_mem`、连接进程、维护任务和 pgvector。该数值是项目初始参考，不是 PostgreSQL 官方最低配置或吞吐量承诺，最终规格仍必须通过实际负载确定。
 
 自建高可用不能只写成“1 主 1 备”。还必须使用经过验证的高可用管理方案完成故障检测、自动切换、主库隔离或 fencing、客户端访问端点切换以及故障域隔离；所选方案需要仲裁或 witness 时还必须部署对应组件，并完成故障演练。