On Sun, Oct 4, 2009 at 9:28 AM, Gurjeet Singh <singh.gurjeet@xxxxxxxxx> wrote: > On Sun, Oct 4, 2009 at 6:32 AM, Robert Haas <robertmhaas@xxxxxxxxx> wrote: >> >> On Sat, Oct 3, 2009 at 2:11 AM, S Arvind <arvindwill@xxxxxxxxx> wrote: >> > Thanks Robert, >> > So for our scenario what is the most important factor to be >> > noted >> > for performance. >> >> Tough to say without benchmarking, but if you have a lot of small >> databases that easily fit in RAM, and a lot of concurrent connections, >> I would think you'd want to spend your hardware $ on maximizing the >> number of cores. >> >> But there are many in this forum who have much more experience with >> these things than me, so take that with a grain of salt... >> >> (You might also want to look at consolidating some of those databases >> - maybe use one database with multiple schemas - that would probably >> help performance significantly.) >> > > I am not sure I understand the reasoning behind it! As long as they are > different objects, how would it help performance if tables are stored in > separate schema, or in separate databases; or are you referring to the > difference in size of system tables and the performance improvement > resulting from keeping all metadata in a single catalog. Yep, if it's all one database you don't have all the different system catalog page competing for space in shared buffers, which is bad especially for a case like this where the individual databases are quite small. I haven't actually measured this myself (so you shouldn't believe me), but there have been other comments about this on this list from time to time. Large numbers of databases seem to hurt the stats collector, too. ...Robert -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance