Re: Confusion on shared buffer

From: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: S Arvind <arvindwill(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Confusion on shared buffer
Date: 2009-10-04 13:28:46
Message-ID: 65937bea0910040628m38b0efabm19d0d183600866b5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sun, Oct 4, 2009 at 6:32 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sat, Oct 3, 2009 at 2:11 AM, S Arvind <arvindwill(at)gmail(dot)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.

Best regards,
--
Lets call it Postgres

gurjeet[(dot)singh](at)EnterpriseDB(dot)com

EnterpriseDB http://www.enterprisedb.com

singh(dot)gurjeet(at){ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Mielke 2009-10-04 14:05:02 Re: Best suiting OS
Previous Message Gerd Koenig 2009-10-04 11:08:19 Re: Postgres performance