Re: Performance issues with parallelism and LIMIT

Hi Tomas!

On 15.11.2025 00:00, Tomas Vondra wrote:
> On 11/14/25 19:20, David Geier wrote:
>>
>> Ooops. That can likely be fixed.
>>

I'll take a look at why this happens the next days, if you think this
approach generally has a chance to be accepted. See below.

>>> And I very much doubt inventing a new ad hoc way to signal workers is
>>> the right solution (even if there wasn't the InstrEndLoop issue).
>>>
>
> Good point, I completely forgot about (2).
>

In that light, could you take another look at my patch?

Some clarifications: I'm not inventing a new way to signal workers but
I'm using the existing SendProcSignal() machinery to inform parallel
workers to stop. I just added another signal PROCSIG_PARALLEL_STOP and
the corresponding functions to handle it from ProcessInterrupts().

What is "new" is how I'm stopping the parallel workers once they've
received the stop signal: the challenge is that the workers need to
actually jump out of whatever they are doing - even if they aren't
producing any rows at this point; but e.g. are scanning a table
somewhere deep down in ExecScan() / SeqNext().

The only way I can see to make this work, without a huge patch that adds
new code all over the place, is to instruct process termination from
inside ProcessInterrupts(). I'm siglongjmp-ing out of the ExecutorRun()
function so that all parallel worker cleanup code still runs as if the
worker processed to completion. I've tried to end the process without
but that caused all sorts of fallout (instrumentation not collected,
postmaster thinking the process stopped unexpectedly, ...).

Instead of siglongjmp-ing we could maybe call some parallel worker
shutdown function but that would require access to the parallel worker
state variables, which are currently not globally accessible.

--
David Geier