我们有一个关于 Server Fault 的问题，提出了一个有趣的问题：
鉴于 Postgres 9.2 可扩展性改进中的可扩展性改进，使用连接池机制来避免与数据库建立额外连接的开销更好，还是连接提高读取性能的开销值得吗？
将它具体与我的环境相关联：我们有一个以数据库为支持且以读取为中心的 Web 应用程序，我们目前在 Postgres 8.4 上运行。
我们的重新实现将于明年启动，同时升级到 9.2，并为每个 Apache 工作进程提供自己与数据库的连接（因此，它自己的 Postgres 后端会在 Apache 工作人员的生命周期内保留）。
根据我们所看到的，这似乎是连接到数据库的开销和让更多工作人员处理读取负载之间的良好平衡，尽管我们还没有进行任何实质性的基准测试来确认这一点。
该实现看起来是否合理？鉴于最近的可扩展性改进，我们是否应该考虑其他选项/连接池机制？
我有一个中等大小的数据库，分布在几个表上，粗略的架构是：
每个表有大约 200,000 行。
我还有一个视图，它基本上将所有这些粘合在一起，以便我可以SELECT使用一堆 ID（通常根据会话 ID 选择它们）并在一个页面上查看所有相关数据。
该视图有效，查询计划的索引利用率似乎正常，但结果并不快：
> EXPLAIN ANALYZE SELECT(*) FROM overlay WHERE test_session=12345;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Merge Right Join (cost=7.19..74179.49 rows=10 width=305) (actual time=10680.129..10680.494 rows=4 loops=1)
Merge Cond: (p.data_id = d.id)
-> Merge Join (cost=7.19..75077.04 rows=183718 width=234) …使用 SQL Server 2008，我发现可以使用获取数据库大小
exec sp_spaceused
此过程返回两个表：
database_name | database_size | unallocated space
reserved | data | index_size | unused
我想创建一个查询，其中 SQL 调用的唯一输出是为 database_size 返回的值。我不想要任何多余的输出（没有表头、列名等）。
有没有一种简单的方法可以做到这一点？