pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedConcurrent Users
3+ messages / 3 participants
[nested] [flat]
* Concurrent Users
@ 2013-08-27 06:05 shyam megha <shyamnguitar@gmail.com>
0 siblings, 2 replies; 3+ messages in thread
From: shyam megha @ 2013-08-27 06:05 UTC (permalink / raw)
To: pgsql-admin
Dear Psql Team,
Hi there! I have two queries of Postgresql 9.x
1.* What is the number of concurrent users who can access the PostgreSQL
9.x server at a time? Is it necessary for me to go for Postgres Advanced
Server plus or any other advanced edition *
In our company we are looking for concurrent access of geospatial data by
100 users at a time.
2.* Also is there maximum storage value that Postgres supports? We are
planning to work with Terabytes of data.*
Regards,
Sam
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Concurrent Users
@ 2013-08-27 06:24 Gabriele Bartolini <Gabriele.Bartolini@2ndQuadrant.it>
parent: shyam megha <shyamnguitar@gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Gabriele Bartolini @ 2013-08-27 06:24 UTC (permalink / raw)
To: shyam megha <shyamnguitar@gmail.com>; +Cc: pgsql-admin
Hi,
On Tue, 27 Aug 2013 11:35:51 +0530, shyam megha
<shyamnguitar@gmail.com> wrote:
> 1. WHAT IS THE NUMBER OF CONCURRENT USERS WHO CAN ACCESS THE
> POSTGRESQL 9.X SERVER AT A TIME? IS IT NECESSARY FOR ME TO GO FOR
> POSTGRES ADVANCED SERVER PLUS OR ANY OTHER ADVANCED EDITION
It all depends on their access patterns. Indeed, it is very easy to
write queries that put down every database on earth. ;)
However, we normally work with vanilla PostgreSQL (the community
maintained project) and manage large numbers of concurrent users and
queries. My suggestion is for you to methodically work on a benchmark
and then evaluate different hardware setups. It takes time and money,
but gives you enough insights on your hardware requirements and
performance. Also, vertical scalability with Postgres has done giant
leaps in the last years.
> In our company we are looking for concurrent access of geospatial
> data by 100 users at a time.
Again, this could lead to a "Yes, Postgres can" as well as "No,
Postgres can't" answer, depending on the nature of your queries.
> 2. ALSO IS THERE MAXIMUM STORAGE VALUE THAT POSTGRES SUPPORTS? WE ARE
> PLANNING TO WORK WITH TERABYTES OF DATA.
Postgres does not have a theoretical limit in storage. However, when
managing terabytes, you need to take some precautions - as any DBMS.
However, a positive message: we normally work with multi-terabyte
databases, with also leading applications/clients in the GIS industry,
and Postgres does its job extremely well. ;)
Cheers,
Gabriele
--
Gabriele Bartolini - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
Gabriele.Bartolini@2ndQuadrant.it - www.2ndQuadrant.it
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Concurrent Users
@ 2013-08-27 16:25 Dustin Wenz <dcw@xtechllc.com>
parent: shyam megha <shyamnguitar@gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Dustin Wenz @ 2013-08-27 16:25 UTC (permalink / raw)
To: shyam megha <shyamnguitar@gmail.com>; +Cc: pgsql-admin
We have a number of medium-sized databases between 30 to 40TB that seem to perform well with some workloads. Our applications are mostly insert-intensive, and we can do several thousand inserts per second with databases in that range. Small inserts seem to be limited in performance by index updates, which need to be as efficient as possible. Indexing sequential values like serial numbers and dates work well, but indexing random numbers like UUIDs does not work well.
It might be worth noting the number of file descriptors available to the user running your database. Postgres can burn through them quickly with the default segsize. While I've not seen Postgres die from this, it doesn't help performance if it's rapidly opening and closing many thousands of data files. On ZFS, I've also seen performance improvements by increasing the blocksize higher than the default.
I would not recommend putting all of your data in a small number of tables if you need maintenance tasks to run as fast as possible (vacuum full, dumps, restores, etc). Postgres is not great at parallelizing maintenance on individual tables. It is, however, pretty good at distributing load between multiple concurrent users performing similar types of queries. If you're only expecting 100 or so users, I don't think you'll have any problems. You will need to tune parameters in postgresql.conf to match your hardware and workload, as described in many places online.
The best advice I can give is to benchmark your schema and usage patterns. Create a database, and put as much data in it as you ever could hope to need, and then even more. Performance will not change linearly; eventually you'll hit some sort of wall. You'll want to know where that is sooner rather than later.
- .Dustin
On Aug 27, 2013, at 1:05 AM, shyam megha <shyamnguitar@gmail.com> wrote:
> Dear Psql Team,
>
> Hi there! I have two queries of Postgresql 9.x
>
> 1. What is the number of concurrent users who can access the PostgreSQL 9.x server at a time? Is it necessary for me to go for Postgres Advanced Server plus or any other advanced edition
>
> In our company we are looking for concurrent access of geospatial data by 100 users at a time.
>
> 2. Also is there maximum storage value that Postgres supports? We are planning to work with Terabytes of data.
>
>
>
> Regards,
> Sam
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2013-08-27 16:25 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2013-08-27 06:05 Concurrent Users shyam megha <shyamnguitar@gmail.com>
2013-08-27 06:24 ` Gabriele Bartolini <Gabriele.Bartolini@2ndQuadrant.it>
2013-08-27 16:25 ` Dustin Wenz <dcw@xtechllc.com>
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