> I want to know if the PostGree has limitations about the concurrent=20=20
> 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 ?
=3D> each one of those uses a little bit of RAM. (see manual) but if
idle=
=20=20
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=
=20=20
time you can get lock problems, for instance transaction A updates row
X=20=
=20
and transaction B updates the same row X, one will have to wait for
the=20=
=20
other to commit or rollback of course. If your transactions last 1
ms=20=20
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=20=20
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=20=20
pooling, or lighttpd/fastcgi, or a proxy, whatever, so the number of open=
=20=20
database connections at the same time won't be that high. Unless you
use=20=
=20
mod_php without connection pooling, in that case it will suck of
course,=20=
=20
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=
=20=20
> 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=
=20=20
only current orders (say orders from this month) are accessed all
the=20=20
time, with old orders being rarely accessed, you want the last 1-2
months'=
=20=20
worth of orders to fit in RAM for fast access (caching) but you don't
need=
=20=20
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=
=20=20
hit it). People have terabytes in postgres and it seems to work ;)
--=20
Sent via pgsql-performance mailing list (pgsql-performance@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
|
