| From: | Nikolay Samokhvalov <nik(at)postgres(dot)ai> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Subtransactions + a long-running transaction leading to performance degradation on standbys |
| Date: | 2021-08-20 05:09:45 |
| Message-ID: | CAM527d8XCfmyVyaHbzJALM_m1g8Ysua7Vr8SGdYMrHtB4mpKBw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 19, 2021 at 10:04 PM Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
wrote:
> I just want to note, that on your screenshot unpatched version runs 400K
> tps, while patched runs 280K tps. I see the dates are different and this
> effect is not observed in [0]. Probably, you run tests on different
> machines.
Indeed, patched Postgres I was testing on 2x smaller EC2 instances, it is
documented in the GitLab issue. But I added an additional note here:
https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/21#note_655731979
> While your experiments clearly shows that patch can save DB from
> degradation under pathological workload it would be great to ensure patch
> does not incur penalty on normal workload.
>
Makes sense. I'll try to find time to make a direct comparison.
I documented all the steps in detail in the GitLab issue, so anyone
interested can reproduce it and explore the problem at different angles.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-08-20 05:23:07 | Re: Two patches to speed up pg_rewind. |
| Previous Message | Andrey Borodin | 2021-08-20 05:04:42 | Re: Subtransactions + a long-running transaction leading to performance degradation on standbys |