| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Thomas Kellerer <shammat(at)gmx(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: FEATURE REQUEST: Role vCPU limit/priority |
| Date: | 2024-01-23 18:25:04 |
| Message-ID: | ZbAEgJA8WAskN9dI@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 23, 2024 at 10:10:27AM -0800, Andres Freund wrote:
> Hi,
>
> On 2024-01-23 13:09:22 +0100, Thomas Kellerer wrote:
> > Yoni Sade schrieb am 21.01.2024 um 19:07:
> > > It would be useful to have the ability to define for a role default
> > > vCPU affinity limits/thread priority settings so that more active
> > > sessions could coexist similar to MySQL resource groups
> > > <https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html>.
> >
> > To a certain extent, you can achieve something like that using Linux cgroups
> >
> > https://www.cybertec-postgresql.com/en/linux-cgroups-for-postgresql/
>
> If you do that naively, you just run into priority inversion issues. E.g. a
> backend holding a critical lwlock not getting scheduled for a while because it
> exceeded it CPU allocation, preventing higher priority processes from
> progressing.
>
> I doubt you can implement this in a robust manner outside of postgres.
FYI, here is an article about priority inversion:
https://www.geeksforgeeks.org/priority-inversion-what-the-heck/
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2024-01-23 18:26:17 | Re: core dumps in auto_prewarm, tests succeed |
| Previous Message | Nathan Bossart | 2024-01-23 18:22:58 | Re: core dumps in auto_prewarm, tests succeed |