Обсуждение: Concurrent Users

 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

We have a number of medium-sized databases between 30 to 40TB that seem to perform well with some workloads. Our
applicationsare 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.
Indexingsequential 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
throughthem quickly with the default segsize. While I've not seen Postgres die from this, it doesn't help performance
ifit's rapidly opening and closing many thousands of data files. On ZFS, I've also seen performance improvements by
increasingthe 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
aspossible (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
parametersin 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
itas you ever could hope to need, and then even more. Performance will not change linearly; eventually you'll hit some
sortof 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
togo 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