From: Tom Lane <tgl@sss.pgh.pa.us>
To: efremov20081@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18330: The query planner chooses the wrong plan when using
 the parallel aggregation function
In-reply-to: <18330-1823d6d59e6936c3@postgresql.org>
References: <18330-1823d6d59e6936c3@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 04 Feb 2024 20:35:02 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4148240.1707092200.1@sss.pgh.pa.us>
Date: Sun, 04 Feb 2024 19:16:40 -0500
Message-ID: <4148241.1707092200@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4148241.1707092200%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> Below is an example of queries. It shows that the query planner chooses
> sequential aggregation instead of parallel, although limit should not have
> affected this.

On what grounds do you assert that LIMIT can be parallelized?
AFAICS it has to be done by a single process to ensure that the
limit is enforced accurately.  So LIMIT below an aggregation
removes the opportunity to parallelize the aggregation.

			regards, tom lane