Results

You can check results even as the test is running with::
```
psql -d results -f reports/report.sql
```
This is unlikely to disrupt the test results very much unless you’ve run an enormous number of tests already. There is also a helper script named summary that shows reports/summary.sql
A helper script named set-times will show how long past tests have taken to complete. This can be useful to get an idea how long the currently running test or test set will actually take to finish.
Other useful reports you can run are in the reports/ directory, including:
- fastest.sql
- summary.sql
- bufreport.sql
- bufsummary.sql
- compromise_params.sql (see below)
Once the tests are done, the results/ directory will include a HTML subdirectory for each test giving its results, in addition to the summary information in the results database.
The results directory will also include its own index HTML file (named index.html) that shows summary information and plots for all the tests.
If you manually adjust the test result database, you can then manually regenerate the summary graphs by running:
```
./webreport
```
If you want to generate a report with selected testsets only (for example sets 1, 6 and 7):
```
./limited_webreport 1,6,7
```
In case you test for static rates amount (for example sets 2, 8 and 9):
```
./rates_webreport 2,8,9
```

Test sets comparison

Runs of pgbench via the runset command are oriented into test sets. Each test that is run will be put into the same test set until you tell the program to switch to a new set. Each test set is assigned both a serial number and a test description.

New test sets are added like this:

psql -d results -c "INSERT INTO testset (info) VALUES ('set name')"

pgbench-tools aims to help compare multiple setups of PostgreSQL. That might be different configuration parameters, different source code builds, or even different versions of the database. One reason the results database is separate from the test database is that you can use a shared results database across multiple test sets, while connecting to multiple test database installations.

The graphs generated by the program will generate a seperate graph pair for each test set, as well as a master graph pair that compares all of them. The graphs in each pair are graphed with a X axis of client count and database scale (size) respectively. The idea is that you might see whether an alternate configuration is better at handling larger data sets, or if it handles concurrency at high client counts better.

Note that all of the built-in pgbench tests use very simple queries. The results can be useful for testing read-only SELECT scaling at different client counts. They can also be useful for seeing how the server handles heavy write volume. But none of these results will change if you alter server parameters that adjust query execution, such as work_mem or effective_cache_size. Many of the useful PostgreSQL parameters to tune for better query execution on larger servers in particular fall into this category. You will not always be able to compare configurations usefully using the built-in pgbench tests. Even for parameters that should impact results, such as shared_buffers or checkpoint_segments, making useful comparisons with pgbench is often difficult.

There is more information about what pgbench is useful for, as well as how to adjust the program to get better results, in the pgbench documentation: http://www.postgresql.org/docs/current/static/pgbench.html