Re: a pool for parallel worker

Hi,

> On Tue, Mar 11, 2025 at 5:39 AM Andy Fan <zhihuifan1213(at)163(dot)com> wrote:
>> Currently when a query needs some parallel workers, postmaster spawns
>> some backend for this query and when the work is done, the backend
>> exit. there are some wastage here, e.g. syscache, relcache, smgr cache,
>> vfd cache and fork/exit syscall itself.
>>
>> I am thinking if we should preallocate (or create lazily) some backends
>> as a pool for parallel worker. The benefits includes:
>>
>> (1) Make the startup cost of a parallel worker lower in fact.
>> (2) Make the core most suitable for the cases where executor need to a
>> new worker to run a piece of plan more. I think this is needed in some
>> data redistribution related executor in a distributed database.
>
> I don't want to discourage your investigation, but two things to consider:
>
> 1. In what state do existing parallel worker use cases expect to see
> their forked worker processes? Any time you reuse processes in a pool,
> you risk bugs if you don't set the pooled process's memory exactly
> "right" -- you don't want to carry over any state from a previous
> iteration. (This is easier in a thread pool, where the thread has
> stack memory but not its own heap.)

We do have such risk, but I want to know if it is something we can't
fix. In a normal backend, it supports different queries one by one with
"previous state", and in this case, we support different partial
plan one by one and there is no DML invoved (we don't support DML in
parallel worker yet), this may make things easier.

Generally I thought it is the duty of the user to reset them correctly.

> 2. For PQ, in particular, how does the cost of serializing +
> deserializing the query itself compare to the cost of fork()ing the
> process?

I didn't try that, however the cost serializing + deserializing should
be able to avoided with global plan cache since we have clean Plan and
PlanState division, leader just need to transfer a pointer to the partial
plan to worker, and worker build its own PlanState for it own. Due to
the lack of global plan cache for now, I did't metion this idea.

As I metioned above, my proposal does not only reduce the cost of fork,
it also want to reduce the cost of building kinds of caches (including
syscache, relcache, smgrcache, vfd and so on) repeatly, some of them may
invoves open, lseek syscall.

My purpose of this thread is wanting some feedback about what could
block a parallel worker from being reused by design. If yes, this idea
should be discard quickly. I just have a very rough idea without any
coding yet.

Thank you for showing interests on this!

--
Best Regards
Andy Fan