Re: O(n) tasks cause lengthy startups and checkpoints

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: O(n) tasks cause lengthy startups and checkpoints
Date: 2021-12-13 18:30:43
Message-ID: AED00E15-7BB1-4514-95A3-9D6658043B61@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/13/21, 9:20 AM, "Justin Pryzby" <pryzby(at)telsasoft(dot)com> wrote:
> On Mon, Dec 13, 2021 at 08:53:37AM -0500, Robert Haas wrote:
>> Another issue is that we don't want to increase the number of
>> processes without bound. Processes use memory and CPU resources and if
>> we run too many of them it becomes a burden on the system. Low-end
>> systems may not have too many resources in total, and high-end systems
>> can struggle to fit demanding workloads within the resources that they
>> have. Maybe it would be cheaper to do more things at once if we were
>> using threads rather than processes, but that day still seems fairly
>> far off.
>
> Maybe that's an argument that this should be a dynamic background worker
> instead of an auxilliary process. Then maybe it would be controlled by
> max_parallel_maintenance_workers (or something similar). The checkpointer
> would need to do these tasks itself if parallel workers were disabled or
> couldn't be launched.

I think this is an interesting idea. I dislike the prospect of having
two code paths for all this stuff, but if it addresses the concerns
about resource usage, maybe it's worth it.

Nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-12-13 18:48:34 Re: isolationtester: add session name to application name
Previous Message Tomas Vondra 2021-12-13 18:25:04 Re: using extended statistics to improve join estimates