public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andrei Lepikhov <[email protected]>
To: Richard Guo <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Andy Fan <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: vignesh C <[email protected]>
Subject: Re: Support run-time partition pruning for hash join
Date: Thu, 5 Sep 2024 09:56:55 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAMbWs49Q=H7P_pE9gjpC0sFky7dAzWCxXczwpwFFkG_VmmHx4Q@mail.gmail.com>
References: <CAMbWs49atE64_JjqrF2+BBZvG-h7afL89wCghg_GmvOHPB_LbQ@mail.gmail.com>
<CAKU4AWpGo7wXEQqvsv13s=Cto3k9QbucW5DJtjwD1a0dF9iTgA@mail.gmail.com>
<CAApHDvp+O0PtZMWomyYg=RE68d1wBnc-yxjJsDK3hmYBnP=-qw@mail.gmail.com>
<CAMbWs49+p6hBxXJHFiSwOtPCSkAHwhJj3hTpCR_pmMiUUVLZ1Q@mail.gmail.com>
<CAApHDvrTwpgYG9UGjBJpMrey36LMpwtEx_2RWrByxSq7NnKqdA@mail.gmail.com>
<CAMbWs488_uMqmyQo0Cq-XrDSiEqiXCnfJtCyhXrWn_HdBen3Tw@mail.gmail.com>
<CAMbWs4_GhDa7+qRbdhLzMTXKZr2naiJc7C+tE1BcK5UVjxqncA@mail.gmail.com>
<[email protected]>
<CAMbWs49bPXs6SVFxJnV4zh_nH6AV0nhHRiJb+E+vFHy9xnvKCA@mail.gmail.com>
<[email protected]>
<CAMbWs49ppLP7oToSj4MiMJ6tbt-nRz-Mwy+ZZMcauAAVJk4gPA@mail.gmail.com>
<CALDaNm2jEJv92Lw=+cGuAQbbMfus7HvAqKeTCtdmk6uCHc9bKA@mail.gmail.com>
<CAMbWs49Pg9TvDrWBHzBDNPe7XP1jTpHukG-nwpNEo-mmr9h4zA@mail.gmail.com>
<CAMbWs49Q=H7P_pE9gjpC0sFky7dAzWCxXczwpwFFkG_VmmHx4Q@mail.gmail.com>
On 19/3/2024 07:12, Richard Guo wrote:
>
> On Tue, Jan 30, 2024 at 10:33 AM Richard Guo <[email protected]
> <mailto:[email protected]>> 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
view thread (6+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Support run-time partition pruning for hash join
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox