pgreplay 1.2.0

Developer: Website: License / Price: Platforms: Databases: Language: Last Updated: Category: Laurenz Albe | More scripts pgreplay.projects.postgresql.org BSD License  Windows / Linux / Mac OS / BSD / Solaris PostgreSQL C/C++ September 21st, 2012, 17:44 GMT C: \ Database Tools

The replayer reads a PostgreSQL log file (not WAL files), extracting all the SQL statements and executing them in the same order and relative time against a PostgreSQL database cluster.

In the first form, the log file infile is replayed at the time it is read.

The database cluster against which you replay the SQL statements must be a clone of the database cluster that generated the logs from the time immediately before the logs were generated.

If the execution of statements gets behind schedule, warning messages are issued that indicate that the server cannot handle the load in a timely fashion.

The idea is to replay a real-world database workload as exactly as possible.

pgreplay is useful for performance tests, particularly in the situations where the developer wants to compare the performance of his PostgreSQL application on different hardware or different operating systems.
 
It can also be helpful where developers want to upgrade their database and want to make sure that the new database version does not suffer from performance regressions that affect it.
 
Moreover, pgreplay can give some feeling as to how his application might scale by allowing to replay the workload at a different speed.

Requirements:

· PostgreSQL

Limitations:

· pgreplay can only replay what is logged by PostgreSQL. This leads to some limitations:
· COPY statements will not be replayed, because the copy data are not logged.
· Fast-path API function calls are not logged and will not be replayed. Unfortunately, this includes the Large Object API.
· Since the log file is always in the server encoding (which you can specify with the -E switch of pgreplay), all SET client_encoding statements will be ignored.
· Since the preparation time of prepared statements is not logged (unless log_min_messages is debug2 or more), these statements will be prepared immediately before they are first executed during replay.
· Performance is not at the same levels with 500 users working at double speed. They are not really the same as 1000 users working at normal speed.

Via: pgreplay 1.2.0