我使用 PostgreSQL 9.2。我有一个大约有 500 万行和 150 列的表。该表根本没有变化（我每年更换一次）。用户在任何某些列上使用各种过滤器查询此表，例如
select * from table where C > 43 and H is not null;
select * from table where A is null and F < 10 and F > 1 and X > 2;
为了提高性能，我计划在表的每一列上创建一个索引。心里有些感慨，先问问各位高手：上面描述的用例，在每一列上都创建一个索引，这样设计好不好？
更新：我必须推测真实的用例。我还不能衡量确切的查询。这是在设计阶段。
服务器配备了良好的RAM和SSD存储，所以现在查询已经“快速”了，当我依次触发类似查询时，我可以感受到缓存的效果。
列的类型为 double、integer、timestamp 和 geometry（显式获取“gist”索引）。
查询将包括 1 到 10 列。通常~6。结果通常小于 20k 行。对一列的查询永远不会与另一列相关。
感谢所有的解释。我将做什么： * 选择我认为最常用的列的 1/4 并创建索引。* 等待更多的测试/使用，然后开始测量/分析查询和用例。
谢谢
我有一个相当大的 PostgreSQL 9.1.3 在 Ubuntu 10.04 上运行。数据分布在多个表空间 = 物理驱动器上。
这些驱动器之一已经消失，因此该表空间的目录不再存在。例如：我丢失了“pg_tblspc/176967555”中的符号链接链接到的目录。
好。状态：重新启动后，该 DBMS 没有出现错误。虽然无法访问该特定数据库
psql: 致命: 无法打开文件 pg_tblspc/176967555/
我试图简单地将这些文件夹创建为空，但是 PG 想要该目录中的一个PG_VERSION和pg_filenode.map文件，我不能简单地创建它。
受影响数据库中 90% 的数据存储在其他正常的表空间中。但是我无法访问数据库中的任何表，因为有些表存储在现已消失的表空间中。
我的目标是从未受影响的表空间读取数据。如果 postgres 只是删除位于该表空间上的任何内容，那就没问题了。
我从丢失的表空间目录中恢复了大部分文件（例如 pg_tblspc/176967555/）。当我将恢复的文件夹放回原位时，PG 在访问该数据库时仍然抱怨丢失的文件 - 一个我无法恢复的文件。
可以使用zero_damaged_pages =true启动 DBMS帮助忽略丢失的文件吗？如果zero_damaged_pages打算用于 ''missing file'' szenario？编辑：不走运 - 它仍然会抱怨丢失的文件：
set zero_damaged_pages = true;
SET
postgres=# \connect problemdb ;
FATAL: could not open file "pg_tblspc/176967555/PG_9.1_201105231/123304298/135285149": No such file or directory
我有哪些选择？
我应该继续尝试使用损坏的表空间恢复数据库吗？这个讨论似乎提供了一些关于如何在单个文件丢失时恢复的技巧。我可以用 dd 以某种方式创建这些文件吗？ …
我正在创建一个 Web 应用程序来检索一个大（4m 行）表的子集。400 万行每年仅更改一次。该表有 200 多列布尔型和数字型。它没有文本列。
用户将查询此表的子集以供下载。
我对PostgreSQL 9.1数据库比较熟悉，我的计划是：
现在..我在这里阅读： https : //stackoverflow.com/questions/10053050/why-is-solr-so-much-faster-than-postgres：
我最近从 Postgres 切换到 Solr，发现查询速度提高了约 50 倍。我们运行的查询涉及多个范围，我们的数据是车辆列表。例如：“查找所有里程 < 50,000, $5,000 < price < $10,000, make=Mazda...”
所以现在我想知道：即使不涉及全文搜索，Solr、Lucene、ElasticSearch、Amazon Cloud Search 搜索是否会比 PostgreSQL 更快？