On Wed, Mar 9, 2011 at 1:45 PM, Gary Carter
<gary.carter@enterprisedb.com> wrote:
> How about stating something along the lines of:
> There are hundreds if not thousands of applications using Postgres that
> experience much heavier transactions loads and run in an exemplary fashion.
> Some examples include:
> Organization name, size of database or simultaneous users, or number of
> transactions per day (granted we may need to leave off the org name, but you
> get the idea)
I don't know exactly the type/size of the election in Estonia, but it
may be similar to an Argentina's Salta Province Open Primary
Elections, where we use PostgreSQL without problems since several
years, the last facts are:
~700 "election departments"
~500 candidates
~500000 registered voters
~32000 rows of accumulate vote totals (votes for a candidate in a
city/region/department)
Each "election department" has an "Election Supervisor" that send the
accumulated results through fax or internet, the image stored in a
PostgreSQL bytea field, then loaded and shown several times to data
entry operators and administrators.
There was syncrhonic replication to a local slave server and
asyncrhonic replication to a remote server (where publication of
results were done) using pyreplica (python triggers and connector):
https://docs.google.com/present/view?id=dd9bm82g_402fjtsdmdd
In importants hours there are around 300 active connections to each database.
The whole process time was around 6 hours (until the last result was
received), the postgresql load was minimal, everything ran smoothly.
Replication logs also works as audit trails (~80000 sql logs), and
they can be used to simulate the load reprocessing them (rebuilding
the database exactly as the data came in) only took minutes.
Database size is 168MB, 1.5GB uncompressed
Server Hardware is normal (quad core xeon X3220, 4GB RAM, SATA RAID1)
Hope this helps,
Best regards,
Mariano Reingart
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com
