On Tue, 27 Aug 2019 at 19:33, Nikolay Samokhvalov <samokhva...@gmail.com> wrote:
> On Tue, Aug 27, 2019 at 3:47 AM ROS Didier <didier....@edf.fr> wrote: > >> Hi >> >> >> >> In my business, one of the things blocking the migration from Oracle to >> PostgreSQL is not having the equivalent of Oracle Real Application Testing . >> >> This product captures a charge in production and replay it in a test >> environment. >> >> this allows to know the impacts of a migration to a newer version, the >> creation of an index.. >> >> is there an equivalent in the PostgreSQL community? >> >> if not, do you think it's technically possible to do it ? >> >> who would be interested in this project ? >> > > Replaying workload might or might not apply well to your case. > > There are several major difficulties if you want to replay workload: > > 1) How to "record" workload. You need to write all your queries to the > Postgres log. Three problems here: > 1a) pgreplay expects log_statements = 'all' while you might prefer > dealing with log_min_duration_statement instead. This is a minor issue > though, quite easy to solve with preprocessing. > 1b) under heavy load, log_min_duration_statement = 0 (or log_statements > = 'all') will lead to performance degradation or even downtime. Possible > solutions are: write to memory, or don't write at all but send over the > network. > 1c) ideally, recoding just queries is not enough. To replay workload "as > is", we need to replay queries with known plans. There is no easy solution > to this problem in the Postgres ecosystem yet. > > why? i prefer queries to take advantage of new plans for example if i'm migrating from 9.5 to 9.6+ i would prefer that, when replaying, the queries use parallel plans so i quickly get if that would somehow be a problem (for example by using more cpu than before) -- Jaime Casanova www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
