Re: Consider parallel for lateral subqueries with limit

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Nancarrow <gregn4422(at)gmail(dot)com>
Cc: James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, brian(at)brianlikespostgres(dot)com
Subject: Re: Consider parallel for lateral subqueries with limit
Date: 2022-01-04 22:30:59
Message-ID: 4152120.1641335459@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Nancarrow <gregn4422(at)gmail(dot)com> writes:
> The patch LGTM.
> I have set the status to "Ready for Committer".

I don't really see why this patch is even a little bit safe.
The argument for it seems to be that a lateral subquery will
necessarily be executed in such a way that each complete iteration
of the subquery, plus joining to its outer rel, happens within a
single worker ... but where is the guarantee of that? Once
you've marked the rel as parallel-safe, the planner is free to
consider all sorts of parallel join structures. I'm afraid this
would be easily broken as soon as you look at cases with three or
more rels. Or maybe even just two. The reason for the existing
restriction boils down to this structure being unsafe:

Gather
NestLoop
Scan ...
Limit
Scan ...

and I don't see how the existence of a lateral reference
makes it any safer.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2022-01-04 22:58:14 Re: [PATCH] Accept IP addresses in server certificate SANs
Previous Message Finnerty, Jim 2022-01-04 22:22:50 Re: Add 64-bit XIDs into PostgreSQL 15