On Wed, 26 Mar 2025, 11:10 Andy Fan, wrote:
>
> Hi,
> >> The boring thing for the pool is it is [dbid + userId] based, which
> >> I mean if the dbid or userId is different with the connection in pool,
> >> they can't be reused. To reduce the effect of UserId, I think if we can
> >> start the poo
Andy Fan writes:
> Hi,
>>> The boring thing for the pool is it is [dbid + userId] based, which
>>> I mean if the dbid or userId is different with the connection in pool,
>>> they can't be reused. To reduce the effect of UserId, I think if we can
>>> start the pool with a superuser and then swit
Hi,
>> The boring thing for the pool is it is [dbid + userId] based, which
>> I mean if the dbid or userId is different with the connection in pool,
>> they can't be reused. To reduce the effect of UserId, I think if we can
>> start the pool with a superuser and then switch the user information
r 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 su
>> 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) Mak
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
(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
