RE: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL

From: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Ted Yu <yuzhihong(at)gmail(dot)com>
Cc: "akapila(at)postgresql(dot)org" <akapila(at)postgresql(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL
Date: 2023-01-11 03:55:25
Message-ID: OS0PR01MB57165F5CC0C9A9C3E96A939B94FC9@OS0PR01MB5716.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, January 11, 2023 10:21 AM Ted Yu <yuzhihong(at)gmail(dot)com> wrote:
> /* First time through, initialize parallel apply worker state hashtable. */
> if (!ParallelApplyTxnHash)
>
> I think it would be better if `ParallelApplyTxnHash` is created by the first
> successful parallel apply worker.

Thanks for the suggestion. But I am not sure if it's worth to changing the
order here, because It will only optimize the case where user enable parallel
apply but never get an available worker which should be rare. And in such a
case, it'd be better to increase the number of workers or disable the parallel mode.

Best Regards,
Hou zj

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2023-01-11 03:56:22 Re: [PATCH] Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
Previous Message Tom Lane 2023-01-11 03:53:12 Re: Can we let extensions change their dumped catalog schemas?