Re: Performance issues with parallelism and LIMIT

On 18.11.2025 16:40, Tomas Vondra wrote:
>>>
>>> But why? The leader and workers already share state - the parallel scan
>>> state (for the parallel-aware scan on the "driving" table). Why couldn't
>>> the leader set a flag in the scan, and force it to end in workers? Which
>>> AFAICS should lead to workers terminating shortly after that.
>>>
>>> All the code / handling is already in place. It will need a bit of new
>>> code in the parallel scans, but but not much I think.
>>>
>>
>> But this would only work for the SeqScan case, wouldn't it? The parallel
>> worker might equally well be executing other code which doesn't produce
>> tuples, such as parallel index scan, a big sort, building a hash table, etc.
>>
>> I thought this is not a viable solution because it would need changes in
>> all these places.
>
> It'd need code in the parallel-aware scans, i.e. seqscan, bitmap, index.
> I don't think you'd need code in other plans, because all parallel plans
> have one "driving" table.
>
> Maybe that's not enough, not sure. If we want to terminate "immediately"
> (and not when getting the next tuple from a scan on the driving table),
> we'd need a different solution.

A sort node for example makes this no longer work. As soon as the sort
node pulled all rows from its driving table, the sort node becomes the
driving table for its parent nodes. If no more tables are involved in
the plan from that point on, early termination no longer works.

--
David Geier