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

From Andrei Lepikhov
Subject Re: Support run-time partition pruning for hash join
Date
Msg-id bc973ed7-b849-462c-ab44-b82da2e59873@gmail.com
Whole thread Raw
In response to Re: Support run-time partition pruning for hash join  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers
On 19/3/2024 07:12, Richard Guo wrote:
> 
> On Tue, Jan 30, 2024 at 10:33 AM Richard Guo <guofenglinux@gmail.com 
> <mailto:guofenglinux@gmail.com>> wrote:
> 
>     Attached is an updated patch.  Nothing else has changed.
> 
> 
> Here is another rebase over master so it applies again.  Nothing else
> has changed.
The patch doesn't apply to the master now.
I wonder why this work was suppressed - it looks highly profitable in 
the case of foreign partitions. And the idea of cost-based enablement 
makes it a must-have, I think.
I have just skimmed through the patch and have a couple of questions:
1. It makes sense to calculate the cost and remember the minimum number 
of pruned partitions when the cost of HJ with probing is still 
profitable. Why don't we disable this probing in runtime if we see that 
the number of potentially pruning partitions is already too low?
2. Maybe I misunderstood the code, but having matched a hashed tuple 
with a partition, it makes sense for further tuples to reduce the number 
of probing expressions because we already know that the partition will 
not be pruned.

-- 
regards, Andrei Lepikhov




pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: In-placre persistance change of a relation
Next
From: jian he
Date:
Subject: updatable view set default interact with base rel generated stored columns