Re: Allowing parallel-safe initplans

On Fri, Jul 14, 2023 at 5:44 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I tried both of those and concluded they'd be too messy for a patch
> that we might find ourselves having to back-patch. So 0001 attached
> fixes it by teaching SS_finalize_plan to treat optimized MIN()/MAX()
> aggregates as if they were already Params. It's slightly annoying
> to have knowledge of that optimization metastasizing into another
> place, but the alternatives are even less palatable.

I tried with 0001 patch and can confirm that the wrong result issue
shown in [1] is fixed.

explain (costs off, verbose) select min(i) from a;
QUERY PLAN
-----------------------------------------------------------
Gather
Output: ($0)
Workers Planned: 1
Params Evaluated: $0 <==== initplan params
Single Copy: true
InitPlan 1 (returns $0)
-> Limit
Output: a.i
-> Index Only Scan using a_i_j_idx on public.a
Output: a.i
Index Cond: (a.i IS NOT NULL)
-> Result
Output: $0
(13 rows)

Now the Gather.initParam is filled and e89a71fb4 does its work to
transmit the Params to workers.

So +1 to 0001 patch.

> I'm still resistant to the idea of kluging EXPLAIN to the extent
> of hiding the EXPLAIN output changes. It wouldn't be that hard
> to do really, but I worry that such a kluge might hide real problems
> in future. So what I did in 0002 was to allow initPlans for an
> injected Gather only if debug_parallel_query = on, so that there
> will be a place for EXPLAIN to show them. Other than the changes
> in that area, 0002 is the same as the previous patch.

Also +1 to 0002 patch.

[1]
https://www.postgresql.org/message-id/CAMbWs48p-WpnLdR9ZQ4QsHZP_a-P0rktAYo4Z3uOHUAkH3fjQg%40mail.gmail.com

Thanks
Richard