Re: Performance issues with parallelism and LIMIT - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Performance issues with parallelism and LIMIT
Date
Msg-id 1116715.1763484704@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance issues with parallelism and LIMIT  (David Geier <geidav.pg@gmail.com>)
Responses Re: Performance issues with parallelism and LIMIT
List pgsql-hackers
David Geier <geidav.pg@gmail.com> writes:
> On 18.11.2025 16:40, Tomas Vondra wrote:
>> 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.

> 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.

You're assuming that the planner will insert Gather nodes at arbitrary
places in the plan, which isn't true.  If it does generate plans that
are problematic from this standpoint, maybe the answer is "don't
parallelize in exactly that way".

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: *_LAST in enums to define NUM* macross
Next
From: Tom Lane
Date:
Subject: Re: IS JSON predicate support for domain base type as JSON/JSONB/BYTEA/TEXT