Re: [QUESTION]Concurrent Access

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: [QUESTION]Concurrent Access
Date: 2008-07-04 16:58:48
Message-ID: 87hcb5ziuv.fsf@dba2.int.libertyrms.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

tlevisilva(at)gmail(dot)com ("Leví Teodoro da Silva") writes:
> Hi guys, How are you ?
> I am from Brazil and i work for a little company and it company is working is medium-big project and we want to use PostGree like the DataBase
> system, but i got some questions.
> I want to know if the PostGree has limitations about the concurrent access, because a lot of people will access this database at the same time.
> I want to know about the limitations, like how much memory do i have to use !? How big could be my database and how simultaneously access this
> database support ?

PostGree is a system I am not familiar with; this list is for
discussion of PostgreSQL, sometimes aliased as "Postgres," so I will
assume you are referring instead to PostgreSQL.

PostgreSQL does have limitations; each connection spawns a process,
and makes use of its own "work_mem", which has the result that the
more connections you configure a particular backend to support, the
more memory that will consume, and eventually your system will
presumably run out of memory.

The size of the database doesn't have as much to do with how many
users you can support as does the configuration that you set up.
--
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/lsf.html
Rules of the Evil Overlord #145. "My dungeon cell decor will not
feature exposed pipes. While they add to the gloomy atmosphere, they
are good conductors of vibrations and a lot of prisoners know Morse
code." <http://www.eviloverlord.com/>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jeffrey Baker 2008-07-05 06:41:38 Re: Fusion-io ioDrive
Previous Message Alan Hodgson 2008-07-04 15:48:19 Re: slow delete