Re: connection establishment versus parallel workers

On Tue, Jan 14, 2025 at 9:42 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Tue, Jan 14, 2025 at 8:50 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> > I gave these a closer look, and I still feel that they are both
> > straightforward and reasonable. IIUC the main open question is whether
> > this might cause problems for other PM signal kinds. Like you, I don't see
> > anything immediately obvious there, but I'll admit I'm not terribly
> > familiar with the precise characteristics of postmaster signals. In any
> > case, 0001 feels pretty safe to me.
>
> Cool. Thanks. I'll think about what else could be affected by that
> change as you say, and if nothing jumps out I'll go ahead and commit
> them, back to 16.

I pushed 0001, addressing the main problem.

I think 0002 described and addressed a real phenomenon but only when
you have multiple sockets with non-empty listen queues. If we fixed
the real underlying problems it wouldn't be an issue. I decided to
unsee that for now.

> I have done a lot more study of this problem and was about to write in
> with some more patches to propose for master only. Basically that
> "100" is destroying performance in this workload, which at least on my
> machine hardly gets any parallelism at all, and only in sporadic
> bursts. You can argue that we aren't designed for high frequency
> short-lived workers (we'll have to reuse workers in some way to be
> good at that), but I don't think it has to fail as badly as it does
> today. It falls off a cliff instead of plateauing: we are so busy
> forking that we don't get around to reaping children, so all our slots
> are (artificially) used up most of the time, and the queries that do
> manage to nab one then sit on their hands for a long time at query
> end. "1" gets much smoother results, but as prophesied in aa1351f1,
> the complexity is terrible, possibly even O(n^3) in places depending
> on how you count: there are many places that scan the whole worker
> list, and one that even scans it again for each item, and that is for
> each thing that starts. IOW we have to fix the complexity
> fundamentally. I have a WIP patch that adds a couple of work queues,
> so that the postmaster never has to consider anything more than the
> head of a queue in various places. More soon...

Here's the WIP code I have up with for that so far.

Remaining opportunities not attempted:
1. When a child exits, we could use a hash table to find it by pid.
2. When looking for a bgworker slot that is not in use, we could do
something better than linear search.