Documentation.
PostgreStats software is well documented. Here you'll find a link to the Installation Guides as well as a general F.A.Q. on features and options set in the software packages.
Installation Guides:
Click right here for complete online installation guides for both PostgreStats and Enterprise.
PostgreStats Frequently Asked Questions:
1. What is PostgreStats and who is it developed for?
2. How are PostgreStats statistics logged and updated?
3. How often should I update my statistics?
4. Will PostgreStats run on a non-Linux server?
5. What is PostgreSQL's Stat Collector and how do I turn it on?
6. What primary statistics are logged in PostgreStats?
7. What specifically is root access required for?
8. What specifically is the Postgres Super-user required for?
9. How can I secure my PostgreStats online statistics?
10. Can I view my statistics on an alternative webserver?
Enterprise Frequently Asked Questions:
1. What is Enterprise and how is it different from PostgreStats?
2. How are Enterprise statistics logged and updated?
3. How often should I update my statistics?
4. Will PostgreStats run on a non-Linux server?
5. How can I secure my Enterprise online statistics?
PostgreStats Frequently Asked Questions:
1. What is PostgreStats and who is it developed for?
PostgreStats is a suite of automated PHP scripts which allows you to easily extract, store, monitor and display database statistics from PostgreSQL's Stat Collector process, online. With several main views including a Monthly Snapshot, Daily Individual Database Statistics, Month VS Month, Weekly Trending and Yearly Snapshot, PostgreStats allows you to view statistical data from the past in a whole new light, allowing you to compare past commit or delete levels for example, on two different days or months.

Statistics are graphed in easy to view vertical bar charts and +/-/= arrows allow you to view how current data on a given month or day for example, compares to the same day or month at a previous time. The purpose of this design was to help PostgreSQL administrators follow the trends of each and all databases in their implementation.

PostgreStats was designed for PostgreSQL admins and developers, and anyone wanting to view their Stat Collector data in a fashion which simply makes more functional sense, based on timed cycles. With PostgreStats being used side-by-side with traditional shell-based monitoring techniques, there's not much you won't know about your implementation.

PostgreStats simply logs and reports data from the PostgreSQL Stat Collector sub-process. It is not designed to be a bench-marking tool for anyone. There are a few on-going debates as to just how accurate the Stat Collector process is and PostgreStats was developed for developers and database admins who are simply interested in reporting what the Stat Collector actively reports on.
2. How are PostgreStats statistics logged & updated?
PostgreStats uses a compact, TXT file based data format. It uses this format rather than a PostgreSQL data source intentionally to reduce the overhead and skewing of statistics throughout the collection process. In short, it reduces the number of queries PostgreStats requires to log your statistics, minimizing impact on over-all performance. When the log-update script is executed by root (VIA cron in most cases), the appropriate log file is either created or updated with new statistics. The log-update script can also be executed by root manually, for example in the event you need to restart the PostgreSQL service and don't want to lose statistical data.
3. How often should I update my statistics?
PostgreStats was designed to be executed by root at any frequency you desire but at least once a day and preferably, just prior to midnight on each day. PostgreSQL statistics by default are cleared out when the Postgres service is restarted so if your implementation requires you to restart your Postgres service throughout the day for whatever reason, utilize cron to parallel this schedule and run statistics prior to any restart if possible, or execute the log-update script manually as root, minimizing statistical data loss.
4. Will PostgreStats run on a non-Linux server?
PostgreStats was developed and tested under a RedHat Linux operating system. While it will most likely run unmodified successfully on many other flavors of Linux and Unix-based systems and even Windows-based servers where unix-style directory syntax is supported, until they are fully tested, they are not officially supported.
5. What is PostgreSQL's Stat Collector and how do I turn it on?
The Statistics Collector is a sub-system of PostgreSQL. It supports the collection of statistics on PostgreSQL server activity. The collector is now on by default in newer PostgreSQL implementations. PostgreStats requires only that the "track_counts" line in the postgresql.conf file be set to "on", which is also the default. "track_activities" and other optional lines in the postgresql.conf file are not required or used in running PostgreStats.
6. What primary statistics are logged in PostgreStats?
From PostgreSQL's stat collector, the primary statistics gathered for viewing in PostgreStats at this time are:
• Commits (recorded in pg_stat_database as field: xact_commit)
• Roll Backs (recorded in pg_stat_database as field: xact_rollback)
• Block Reads (recorded in pg_stat_database as field: blks_read)
• Buffer Hits (recorded in pg_stat_database as field: blks_hit)
• User Table Inserts (recorded in pg_stat_user_tables as field: n_tup_ins)
• User Table Updates (recorded in pg_stat_user_tables as field: n_tup_upd)
• User Table Deletes (recorded in pg_stat_user_tables as field: n_tup_del)
• Sequence Scans (recorded in pg_stat_user_tables as field: seq_scan)
• Index Scans (recorded in pg_stat_user_tables as field: idx_scan)
• Sequence Scans Rows Used (recorded in pg_stat_user_tables as field: seq_tup_read)
• Index Scans Rows Used (recorded in pg_stat_user_tables as field: idx_tup_fetch)
7. What specifically is root access required for?
The PostgreStats main log-update script was designed to be cronned / executed by root only. For maximum security, it was not designed to be executed VIA CGI, online in any fashion or by any other system user. As stated above, once installation of PostgreStats is completed, we recommend the main log-update script be chown / chmod root with root-level only privileges.

Root is also required by the primary log-update script as it will dynamically SU to the PostgreSQL super-user who will then be responsible for issuing PostgreSQL's built-in pg_stat_reset function, zeroing out statistics for the next cycle.
8. What specifically is the Postgres Super-user required for?
As stated above, the PostgreSQL super-user, is required to initiate and execute PostgreSQL's built-in pg_stat_reset function, zeroing out statistics for each database. This function is called once per database, per log-update.
9. How can I secure my PostgreStats online statistics?
There are several methods for securing your PostgreStats directory, statistics and files. If you run Apache, you can activate PostgreStat's built in PHP / Apache Basic Realm Authentication feature in the PostgreStats conf file. When activated this will require a standard username / password to access your statistics. Standard security of this PHP / Apache function applies.

For added security, it is recommended you view your online statistics through the HTTPS protocol, further securing your data. Standard authentication in addition to using SSL will maximize security. A third method to further secure your PostgreStats implementation (in addition to), once your install of PostgreStats is completed, we recommend you chown / chmod the log-update script to root, with root only privileges, making certain it is not executed by anyone but root, who it's intended for.
10. Can I view my statistics on an alternative webserver?
Yes. For developers who do not run Apache on their PostgreSQL servers, PostgreStats has an automated, configurable FTP-to-Webserver feature. When this feature is on, each time the cron_log_update.php script is executed, PostgreStats will FTP your implementation to the alternative webserver. For security purposes, this feature was designed to be used where the webserver is within the network and has an internal IP.

NOTE: If you plan to use the FTP-to-Webserver feature, make sure the server path to PostgreStats is the same on both the database server and webserver.
Enterprise Frequently Asked Questions:
1. What is Enterprise and how is it different from PostgreStats?
Enterprise is PostgreStats re-built from the ground up specifically for multi-server environments OR for single server environments where you want to get more out of your PostgreSQL statistics. Until now, if you had multiple DB servers, each would require an implementation of PostgreStats. Where Postgrestats was developed to be installed and executed from the database server, Enterprise is designed to be installed on any web-server having access to the DBs.

Enterprise differs hugely from PostgreStats in that it uses the PostgreSQL database to store statistics VS txt flat-files. It has built-in features such as stat pausing on both server and database levels as well as a "replication mode" where you can view stats from databases with the same name on multiple servers in either split or combined level views. Enterprise also has a data-aware navigation as well as many updates to the core code-base.
2. How are Enterprise statistics logged and updated?
Like PostgreStats, Enterprise statistics are logged VIA a scheduled cron-job where the main ps_cron.php file is executed at any interval you choose. Unlike PostgreStats which requires both Root and the PostgreSQL super-user to reset statistics altogether on update, Enterprise doesn't require any of these, including access to pg_stat_reset().
3. How often should I update my statistics?
Enterprise uses the PostgreSQL database to store statistics so both collecting and displaying statistics are quick processes. Because of this, it's designed to be executed at higher frequencies. Your specific needs will determine how often you collect statistics but a good starting point might be once an hour. Like PostgreStats, it is still important, regardless of your cron schedule, that ps_cron.php be executed at least once per day and as close (but prior to) midnight as possible.
4. Will PostgreStats run on a non-Linux server?
PostgreStats was developed and tested under a RedHat Linux operating system. While it will most likely run unmodified successfully on many other flavors of Linux and Unix-based systems, they are not officially supported.
5. How can I secure my Enterprise online statistics?
There are several things you can do to secure your implementation. We recommend first, once your stats are set up and collecting successfully, to chmod / chown the ps_cron.php script as being owned by root and executing the cron-job as root only. Secondly, because PostgreStats has a full-featured online GUI, we strongly recommend you only view statistics and modify your data in an SSL environment where any data to and from the DBs will be encrypted.