| From: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Cc: | Pengchengliu <pengchengliu(at)tju(dot)edu(dot)cn>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: suboverflowed subtransactions concurrency performance optimize |
| Date: | 2021-12-08 15:34:21 |
| Message-ID: | CANbhV-Ht6HUEWfLa6QaKQRX6OcYNa6T2g1irTaAbJazjmLphbg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 1 Dec 2021 at 06:41, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> > On review, I think it is also possible that we update subtrans ONLY if
> > someone uses >PGPROC_MAX_CACHED_SUBXIDS.
> > This would make subtrans much smaller and avoid one-entry-per-page
> > which is a major source of cacheing.
> > This would means some light changes in GetSnapshotData().
> > Let me know if that seems interesting also?
>
> I'm afraid of unexpected performance degradation. When the system runs fine, you provision a VM of some vCPU\RAM, and then some backend uses a little more than 64 subtransactions and all the system is stuck. Or will it affect only backend using more than 64 subtransactions?
That is the objective: to isolate the effect to only those that
overflow. It seems possible.
--
Simon Riggs http://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2021-12-08 15:39:34 | Re: Question on not-in and array-eq |
| Previous Message | Tom Lane | 2021-12-08 15:25:32 | Re: Readd use of TAP subtests |