Alastair McKinley writes:
> Thanks for solving the mystery. I think this might be a missing point in
> section 15.2 in the docs.
> I wonder will this ever be improved or should I just write to temporary
> tables instead of return query?
I just posted a patch to improve that [1], but it's not s
Sent: 21 March 2020 20:50
To: Alastair McKinley
Cc: Adrian Klaver ;
pgsql-general@lists.postgresql.org
Subject: Re: Explain says 8 workers planned, only 1 executed
Unfortunately, return query will never use parallel workers. See:
https://stackoverflow.com/q/58079898/895640 and
https
namic queries in plpgsql functions? Does the outer function
> need to be parallel safe?
> Might a stored proc work better?
>
> Best regards,
>
> Alastair
>
>
> ------------------
> *From:* Adrian Klaver
> *Sent:* 21 March 2020 17:38
> *To:* Alastair McKinley ;
> pgsql-general@lists.postg
Sent: 21 March 2020 17:38
To: Alastair McKinley ;
pgsql-general@lists.postgresql.org
Subject: Re: Explain says 8 workers planned, only 1 executed
On 3/21/20 10:25 AM, Alastair McKinley wrote:
> Hi all,
>
> I have a long running query that I have tweaked along with config (e.g.
> min_
On 3/21/20 10:25 AM, Alastair McKinley wrote:
Hi all,
I have a long running query that I have tweaked along with config (e.g.
min_parallel_table_scan_size) to execute nicely and very fast in
parallel which works as expected executed directly from psql client.
The query is then embedded in a
Hi all,
I have a long running query that I have tweaked along with config (e.g.
min_parallel_table_scan_size) to execute nicely and very fast in parallel which
works as expected executed directly from psql client. The query is then
embedded in a psql function like "return query select * from
