Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning
От | Amit Langote |
---|---|
Тема | Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning |
Дата | |
Msg-id | CA+HiwqFin4GNmvDA5Kk3yB=NkJ8L_JS6L70M2iqGW4vJTnYKJg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Список | pgsql-hackers |
On Wed, Sep 27, 2023 at 8:07 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > On Wed, Sep 27, 2023 at 2:30 PM Amit Langote <amitlangote09@gmail.com> wrote: > > Just out of curiosity, is their not being present in join_info_list > > problematic in some manner, such as missed optimization opportunities > > for child joins? I noticed there is a loop over join_info_list in > > add_paths_to_join_rel(), which does get called for child joinrels. I > > know this a bit off-topic for the thread, but thought to ask in case > > you've already thought about it. > > The function has a comment and code to take care of this at the very beginning > /* > * PlannerInfo doesn't contain the SpecialJoinInfos created for joins > * between child relations, even if there is a SpecialJoinInfo node for > * the join between the topmost parents. So, while calculating Relids set > * representing the restriction, consider relids of topmost parent of > * partitions. > */ > if (joinrel->reloptkind == RELOPT_OTHER_JOINREL) > joinrelids = joinrel->top_parent_relids; > else > joinrelids = joinrel->relids; Ah, that's accounted for. Thanks. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: