关于postgres大表的问题，千万条记录

moremore2

做了一个采集流量的数据库，采用单张表记录每一天的流量。以3月10日为例，大概有5千6百万条记录。发现性能急剧下降。有这么几个问题，请高手指点：
1、postgres对大表的支持如何，在记录数超过千万条的情况下，是否分多张表有更好的性能？我只知道oracle对大表有特殊的支持，存储方式也做了优化的。
2、执行vacuumdb花费半个小时也未能完成。建索引也极为耗时。那么采用B－tree索引对单张大表的性能有多大的影响？index对聚合操作又能提供多大的帮助？
3、流量采集是通过copy文本到数据库的，每次接近50万条。在这种情况下，如果要建索引，是删掉重建还是让数据库自动重建开销更小？
4、启动时采用－B参数对性能的影响能有多大？

   机器配置是hp服务器，双路cpu，p4 2.5G，4GB内存，740G raid5 HD。操作系统是freebsd 5.2。postgres 7.3.4，表结构只有7个字段，极为简单。主要是一些聚合操作供统计之用。

雨中漫步

每个表都有几千万的数据？
采用每天一个表不知如何？

moremore2

可能是我刚才没有说清楚，现在就是每天一张表，每天的数据有5千万条左右：p
做这个数据库有部分原因也是对postgres的极限性能感到好奇。
对于index我的理解是在没有index的情况下，做一个查询是要顺序扫描整张表的，而通过B－tree算法，对某条记录或者某部分记录的查询通过对单独字段的索引来进行，不再从第一条开始顺序查找，因而提高了速度。但因为此数据库主要是聚合操作，因此怀疑index的效用。
也许更适合此类项目的是db、gdm这样的非关系型数据库，可是没有sql这样的强力工具，编程的量就比较大了。
呵呵，令人高兴的是postgres的稳定性得到了验证，同时进行大量查询和插入操作时，通过top可以观察到postmaster派生出的postgres进程均匀的分配了cpu资源。虽然慢点，但总能完成。

netkiller

你只的db,gdm 是不是那种key,value 的数据库.
如果是.你可以使用LDAP.他是使用bdb,gdbm...做数据库.
可以通过ldap://xxx来查询.
如果你要更复杂的.可以用JDBC LDAP.
可以使用SQL访问LDAP