Re: Support run-time partition pruning for hash join - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Support run-time partition pruning for hash join
Date
Msg-id CAMbWs49ppLP7oToSj4MiMJ6tbt-nRz-Mwy+ZZMcauAAVJk4gPA@mail.gmail.com
Whole thread Raw
In response to Re: Support run-time partition pruning for hash join  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: Support run-time partition pruning for hash join
List pgsql-hackers

On Mon, Nov 6, 2023 at 11:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
Please look at a warning and an assertion failure triggered by the
following script:
set parallel_setup_cost = 0;
set parallel_tuple_cost = 0;
set min_parallel_table_scan_size = '1kB';

create table t1 (i int) partition by range (i);
create table t1_1 partition of t1 for values from (1) to (2);
create table t1_2 partition of t1 for values from (2) to (3);
insert into t1 values (1), (2);

create table t2(i int);
insert into t2 values (1), (2);
analyze t1, t2;

select * from t1 right join t2 on t1.i = t2.i;

2023-11-06 14:11:37.398 UTC|law|regression|6548f419.392cf5|WARNING:  Join partition pruning $0 has not been performed yet.
TRAP: failed Assert("node->as_prune_state"), File: "nodeAppend.c", Line: 846, PID: 3747061

Thanks for the report!  I failed to take care of the parallel-hashjoin
case, and I have to admit that it's not clear to me yet how we should do
join partition pruning in that case.

For now I think it's better to just avoid performing join partition
pruning for parallel hashjoin, so that the patch doesn't become too
complex for review.  We can always extend it in the future.

I have done that in v5.  Thanks for testing!

Thanks
Richard
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Remove distprep
Next
From: Amit Kapila
Date:
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node