From: | Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com> |
---|---|
To: | Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
Cc: | ROS Didier <didier(dot)ros(at)edf(dot)fr>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PostgreSQL and Real Application Testing (RAT) |
Date: | 2019-08-28 00:56:27 |
Message-ID: | CAJGNTeP6B+kETzr1KAcX_YrT17rkZOooA9RNXGCiaHo-U5quOw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 27 Aug 2019 at 19:33, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
wrote:
> On Tue, Aug 27, 2019 at 3:47 AM ROS Didier <didier(dot)ros(at)edf(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Barwick | 2019-08-28 01:13:38 | Re: doc: clarify "pg_signal_backend" default role |
Previous Message | Nikolay Samokhvalov | 2019-08-28 00:32:44 | Re: PostgreSQL and Real Application Testing (RAT) |