Re: Performance issues with parallelism and LIMIT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Geier <geidav(dot)pg(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, dilipbalaut(at)gmail(dot)com
Subject: Re: Performance issues with parallelism and LIMIT
Date: 2025-11-18 16:51:44
Message-ID: 1116715.1763484704@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Geier <geidav(dot)pg(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-11-18 17:01:19 Re: IS JSON predicate support for domain base type as JSON/JSONB/BYTEA/TEXT
Previous Message Tom Lane 2025-11-18 16:49:12 Re: *_LAST in enums to define NUM* macross