On Sun, Oct 4, 2009 at 9:28 AM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
> On Sun, Oct 4, 2009 at 6:32 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Sat, Oct 3, 2009 at 2:11 AM, S Arvind <arvindwill@gmail.com> 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
