public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andrei Lepikhov <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: Alexander Pyhalov <[email protected]>
Cc: Jaime Casanova <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: [email protected]
Cc: KaiGai Kohei <[email protected]>
Cc: a.rybakina <[email protected]>
Cc: Белялов Дамир Наилевич <[email protected]>
Subject: Re: Asymmetric partition-wise JOIN
Date: Mon, 16 Oct 2023 11:51:24 +0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAPpHfdvwp7cBWs=iBv7zc7e9NOWQf0TmcwNNzw=--H1qFoBcNA@mail.gmail.com>
References: <CAOP8fzaVL_2SCJayLL9kj5pCA46PJOXXjuei6-3aFUV45j4LJQ@mail.gmail.com>
<CALtqXTfhC=FfHe0+_RP84w=X13d+z+akyN_ROCEQAyQigW7PDA@mail.gmail.com>
<163118104689.1167.8241611097516113795.pgcf@coridan.postgresql.org>
<20210909153833.GA6514@ahch-to>
<[email protected]>
<[email protected]>
<[email protected]>
<CAPpHfdtm2_xM1WP1=Jyj9vRQ5jNu-kSqaoazvUp_s_7Cq0906A@mail.gmail.com>
<[email protected]>
<CAPpHfdvwp7cBWs=iBv7zc7e9NOWQf0TmcwNNzw=--H1qFoBcNA@mail.gmail.com>
On 15/10/2023 17:25, Alexander Korotkov wrote:
> On Sun, Oct 15, 2023 at 8:40 AM Andrei Lepikhov
> <[email protected]> wrote:
>> Thanks for such detailed feedback!
>> The rationale for this patch was to give the optimizer additional ways
>> to push down more joins into foreign servers. And, because of
>> asynchronous append, the benefit of that optimization was obvious.
>> Unfortunately, we hadn't found other applications for this feature,
>> which was why this patch was postponed in the core.
>> You have brought new ideas about applying this idea locally. Moreover,
>> the main issue of the patch was massive memory consumption in the case
>> of many joins and partitions - because of reparameterization. But now,
>> postponing the reparameterization proposed in the thread [1] resolves
>> that problem and gives some insights into the reparameterization
>> technique of some fields, like lateral references.
>> Hence, I think we can restart this work.
>> The first thing here (after rebase, of course) is to figure out and
>> implement in the cost model cases of effectiveness when asymmetric join
>> would give significant performance.
>
> Great! I'm looking forward to the revised patch
Before preparing a new patch, it would be better to find the common
ground in the next issue:
So far, this optimization stays aside, proposing an alternative path for
a join RelOptInfo if we have an underlying append path in the outer.
My back burner is redesigning the approach: asymmetric join doesn't
change the partitioning scheme and bounds of the partitioned side. So,
it looks consecutive to make it a part of partitionwise_join machinery
and implement it as a part of the try_partitionwise_join /
generate_partitionwise_join_paths routines.
--
regards,
Andrey Lepikhov
Postgres Professional
view thread (4+ 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], [email protected], [email protected], [email protected]
Subject: Re: Asymmetric partition-wise 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