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
On Tue, 11 Mar 2025 at 17:38, Andy Fan wrote:
>
>
>
> Hi,
>
Hi!
> 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
Hi,
> On Tue, Mar 11, 2025 at 5:39 AM Andy Fan 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/
On Tue, Mar 11, 2025 at 5:39 AM Andy Fan 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
