From: PFC <lists@peufeu.com>
To: Leví Teodoro da Silva <tlevisilva@gmail.com>
To: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: [QUESTION]Concurrent Access
Date: Thu, 03 Jul 2008 14:56:27 +0200
Message-ID: <op.udpvkdv6cigqcu@apollo13.peufeu.com> (raw)
In-Reply-To: <4a74ba520807021131l28308633yf0ad5416a7055f9@mail.gmail.com>
References: <4a74ba520807021131l28308633yf0ad5416a7055f9@mail.gmail.com>
> 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.
PostgreSQL has excellent concurrency provided you use it correctly.
But what do you mean by concurrent access ?
* Number of opened Postgres connections at the same time ?
=> each one of those uses a little bit of RAM. (see manual) but if idle
they don't use CPU.
* Number of opened transactions at the same time ?
(between BEGIN and COMMIT)
If your transactions are long and you have many transactions at the same
time you can get lock problems, for instance transaction A updates row X
and transaction B updates the same row X, one will have to wait for the
other to commit or rollback of course. If your transactions last 1 ms
there is no problem, if they last 5 minutes you will suffer.
* Number of queries executing at the same time ?
This is different from above, each query will eat some CPU and IO
resources, and memory too.
* Number of concurrent HTTP connections to your website ?
If you have a website, you will probably use some form of connection
pooling, or lighttpd/fastcgi, or a proxy, whatever, so the number of open
database connections at the same time won't be that high. Unless you use
mod_php without connection pooling, in that case it will suck of course,
but that's normal.
* Number of people using your client ?
See number of idle connections above. Or use connection pool.
> I want to know about the limitations, like how much memory do i have to
> use
That depends on what you want to do ;)
> How big could be my database ?
That depends on what you do with it ;)
Working set size is more relevant than total database size.
For instance if your database contains orders from the last 10 years, but
only current orders (say orders from this month) are accessed all the
time, with old orders being rarely accessed, you want the last 1-2 months'
worth of orders to fit in RAM for fast access (caching) but you don't need
RAM to fit your entire database.
So, think about working sets not total sizes.
And there is no limit on the table size (well, there is, but you'll never
hit it). People have terabytes in postgres and it seems to work ;)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: lists@peufeu.com, tlevisilva@gmail.com
Subject: Re: [QUESTION]Concurrent Access
In-Reply-To: <op.udpvkdv6cigqcu@apollo13.peufeu.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox