On 1/8/2024 20:56, Alexander Korotkov wrote:
On Tue, Apr 2, 2024 at 6:07 AM Andrei Lepikhov
wrote:
Actually, the idea I tried to express is the combination of #1 and #2:
to build individual plan for every partition, but consider the 'Common
Resources'. Let me explain this a bit more.
Thanks fo
On Sun, May 5, 2024 at 5:55 PM Andrei Lepikhov wrote:
> On 18/10/2023 16:59, Ashutosh Bapat wrote:
> > On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
> >>> The relid is also used to track the scans at executor level. Since we
> >>> have so many scans on A, each may be using different plan, we wi
Hi!
On Tue, Apr 2, 2024 at 6:07 AM Andrei Lepikhov
wrote:
> On 15/10/2023 13:25, Alexander Korotkov wrote:
> > Great! I'm looking forward to the revised patch.
> Revising the code and opinions before restarting this work, I found two
> different possible strategies mentioned in the thread:
> 1.
On 15/10/2023 13:25, Alexander Korotkov wrote:
Great! I'm looking forward to the revised patch.
Revising the code and opinions before restarting this work, I found two
different possible strategies mentioned in the thread:
1. 'Common Resources' shares the materialised result of the inner table
On 18/10/2023 16:59, Ashutosh Bapat wrote:
On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
wrote:
But the clauses of A parameterized by P will produce different
translations for each of the partitions. I think we will need
different RelOptInfos (for A) to store these translations.
Does the
On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
wrote:
>
> > But the clauses of A parameterized by P will produce different
> > translations for each of the partitions. I think we will need
> > different RelOptInfos (for A) to store these translations.
>
> Does the answer above resolved this issu
On 17/10/2023 17:09, Ashutosh Bapat wrote:
On Tue, Oct 17, 2023 at 2:05 PM Andrei Lepikhov
wrote:
On 16/10/2023 23:21, Ashutosh Bapat wrote:
On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov
Whenever I visited this idea, I hit one issue prominently - how would
we differentiate different scans
On Tue, Oct 17, 2023 at 2:05 PM Andrei Lepikhov
wrote:
>
> On 16/10/2023 23:21, Ashutosh Bapat wrote:
> > On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov
> > Whenever I visited this idea, I hit one issue prominently - how would
> > we differentiate different scans of the non-partitioned relation.
On 16/10/2023 23:21, Ashutosh Bapat wrote:
On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov
Whenever I visited this idea, I hit one issue prominently - how would
we differentiate different scans of the non-partitioned relation.
Normally we do that using different Relids but in this case we
wouldn
On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov
wrote:
>
> >
> > 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 R
On 15/10/2023 17:25, Alexander Korotkov wrote:
On Sun, Oct 15, 2023 at 8:40 AM Andrei Lepikhov
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
On Sun, Oct 15, 2023 at 8:40 AM Andrei Lepikhov
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.
On 15/10/2023 07:18, Alexander Korotkov wrote:
Hi Alexander,
Hi Andrey,
Thank you for your work on this subject.
On Mon, Jan 17, 2022 at 1:42 PM Alexander Pyhalov
wrote:
The patch does not longer apply cleanly, so I rebased it. Attaching
rebased version.
Not surprising that the patch doesn'
Hi Alexander,
Hi Andrey,
Thank you for your work on this subject.
On Mon, Jan 17, 2022 at 1:42 PM Alexander Pyhalov
wrote:
> The patch does not longer apply cleanly, so I rebased it. Attaching
> rebased version.
Not surprising that the patch doesn't apply after 1.5 years since the
last message.
ber of paths in complex queries. It
+ * can be a task for future work.
+ */
+ return NIL;
+ }
+
+ populate_joinrel_with_paths(root,
+ child_rel,
+ inner_rel,
+ child_joinrel,
+ child_sjinfo,
+ child_restrictlist);
+
+ /* Give up if asymmetric part
child_joinrel,
+
child_sjinfo,
+
child_restrictlist);
+
+ /* Give up if asymmetric partition-wise join is not available */
+ if (child_joinrel->pathlist == NIL)
+
+ return NIL;
+ }
+
+ populate_joinrel_with_paths(root,
+ child_rel,
+ inner_rel,
+ child_joinrel,
+ child_sjinfo,
+ child_restrictlist);
+
+ /* Give up if asymmetric partition-wise join is not available */
+ if (child_joinrel->pathlist == NIL)
+ return NIL;
+
+
On Thu, Sep 09, 2021 at 09:50:46AM +, Aleksander Alekseev wrote:
> It looks like this patch needs to be updated. According to
> http://cfbot.cputube.org/ it applies but doesn't pass any tests. Changing the
> status to save time for reviewers.
>
> The new status of this patch is: Waiting on A
It looks like this patch needs to be updated. According to
http://cfbot.cputube.org/ it applies but doesn't pass any tests. Changing the
status to save time for reviewers.
The new status of this patch is: Waiting on Author
On Thu, Jul 15, 2021 at 11:32 AM Andrey Lepikhov
wrote:
> On 5/7/21 23:15, Zhihong Yu wrote:
> > On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > +* Can't imagine situation when join relation already
> > exists. But in
> > +*
child_rel,
+
inner_rel,
+
child_joinrel,
+
child_sjinfo,
+
Andrey Lepikhov писал 2021-07-06 12:28:
On 5/7/21 23:15, Zhihong Yu wrote:
On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
+ * Can't imagine situation when join relation already
exists. But in
+ * the 'partition_join' regression te
inner_rel,
+
child_joinrel,
+
child_sjinfo,
+
child_restrictlist);
+
+ /* Give up if asymm
On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov
wrote:
> On 18/6/21 15:02, Alexander Pyhalov wrote:
> > Andrey Lepikhov писал 2021-05-27 07:27:
> >> Next version of the patch.
> >> For searching any problems I forced this patch during 'make check'
> >> tests. Some bugs were found and fixed.
> >
>
inner_rel,
+
child_joinrel,
+
child_sjinfo,
+
child_restrictlist);
+
+
Andrey Lepikhov писал 2021-05-27 07:27:
Next version of the patch.
For searching any problems I forced this patch during 'make check'
tests. Some bugs were found and fixed.
Hi.
I've tested this patch and haven't found issues, but I have some
comments.
src/backend/optimizer/path/joinrels.c:
inner_rel,
+
child_join_rel,
+
child_sjinfo,
+
child_restrictlist)
On 11/30/20 7:43 PM, Anastasia Lubennikova wrote:
This entry was inactive during this CF, so I've marked it as returned
with feedback. Feel free to resubmit an updated version to a future
commitfest.
I return the patch to commitfest. My current reason differs from reason
of origin author.
This
!enable_partitionwise_join)
+ return;
+
+ if (IS_OTHER_REL(outer_rel) || IS_OTHER_REL(inner_rel))
+ return;
+
+ if (jointype != JOIN_INNER && jointype != JOIN_LEFT)
+ return;
+
+ foreach (lc, outer_rel->pathlist)
+ {
+ AppendPath *append_path = lfirst(lc);
+
+ /*
+ * MEMO: We assume this
table-scan, symmetric or asymmetric
+ * partition-wise join. It is not correct right now, however,
a hook
+ * on add_path() to give additional decision for path removel
allows
+ * to retain this kind of AppendPath, regardless of its cost.
2. Why do we wrap extract_asymmet
am not a big expert in this area, so I'm sorry if questions are obvious.
1. What would happen if this assumption is not met?
+ * MEMO: We assume this pathlist keeps at least one AppendPath that
+ * represents partitioned table-scan, symmetric or asymmetric
+ * parti
an
> > > be cheaper.
> > >
> > > On the other hands, it has a downside because t1 must be read 3 times and
> > > hash table also must be built 3 times. It increases the expected cost,
> > > so planner
> > > may not choose the asymme
> On 21 Aug 2020, at 08:02, Andrey V. Lepikhov
> wrote:
>
> On 7/1/20 2:10 PM, Daniel Gustafsson wrote:
>>> On 27 Dec 2019, at 08:34, Kohei KaiGai wrote:
>>> The attached v2 fixed the problem, and regression test finished correctly.
>> This patch no longer applies to HEAD, please submit an reba
oinrel_with_paths(root,
+ child_rel,
+ inner_rel,
+ child_join_rel,
+ child_sjinfo,
+ child_restrictlist);
+
+ /* Give up if asymmetric partition-wise join is not available */
+ if (child_join_rel->pathlist == NIL)
+ return NIL;
+
+ set_cheapest(child_join_rel);
+ result =
On 12/27/19 12:34 PM, Kohei KaiGai wrote:
The attached v2 fixed the problem, and regression test finished correctly.
Using your patch I saw incorrect value of predicted rows at the top node
of the plan: "Append (cost=270.02..35165.37 rows=40004 width=16)"
Full explain of the query plan see in a
> On 27 Dec 2019, at 08:34, Kohei KaiGai wrote:
> The attached v2 fixed the problem, and regression test finished correctly.
This patch no longer applies to HEAD, please submit an rebased version.
Marking the entry Waiting on Author in the meantime.
cheers ./daniel
Hi Thomas,
On 12/27/19 2:34 AM, Kohei KaiGai wrote:
>
This crash was reproduced on our environment also.
It looks to me adjust_child_relids_multilevel() didn't expect a case
when supplied 'relids'
(partially) indicate normal and non-partitioned relation.
It tries to build a new 'parent_relids' t
Hello,
This crash was reproduced on our environment also.
It looks to me adjust_child_relids_multilevel() didn't expect a case
when supplied 'relids'
(partially) indicate normal and non-partitioned relation.
It tries to build a new 'parent_relids' that is a set of
appinfo->parent_relid related to
On Sat, Aug 24, 2019 at 05:33:01PM +0900, Kohei KaiGai wrote:
> On the other hands, it eventually consumes almost equivalent amount
> of memory to load the inner relations, if no leafs are pruned, and if we
> could extend the Hash-node to share the hash-table with sibling
> join-nodess.
The patch
> > hash table also must be built 3 times. It increases the expected cost,
> > so planner
> > may not choose the asymmetric partition-wise join plan.
>
> What if you include the partition constraint as a filter on t1? So you get:
>
> ptable X t1 =
> (ptable_p0 X (σ
gt; may not choose the asymmetric partition-wise join plan.
What if you include the partition constraint as a filter on t1? So you get:
ptable X t1 =
(ptable_p0 X (σ hash(dist)%4=0 (t1))) +
(ptable_p1 X (σ hash(dist)%4=1 (t1))) +
(ptable_p2 X (σ hash(dist)%4=2 (t1))) +
(ptable_p3 X (σ has
Hello,
Even though nobody has respond the thread, I tried to make a prototype of
the asymmetric partition-wise join support.
This feature tries to join non-partitioned and partitioned relation
before append.
See the example below:
create table ptable (dist int, a int, b int) partition by hash
(cost=0.00..1.50 rows=50 width=4) (actual time=0.003..0.008 rows=50
loops=1)
Planning Time: 0.614 ms
Execution Time: 1396.131 ms
(25 rows)
How about your opinions for this kind of asymmetric partition-wise
JOIN support by the optimizer?
I think we can harmlessly push-down inner-join and left-
43 matches
Mail list logo
