Andrey Lepikhov writes:
> Thanks, I have written the letter because of some doubts too. But only
> one weak point I could imagine - if someday sql standard will be changed.
Yeah, if they ever decide that LATERAL should be allowed to reference a
previous sub-query of UNION ALL, that'd probably
On 22/12/2022 06:50, Tom Lane wrote:
2. Iterative passes along the append_rel_list for replacing vars in the
translated_vars field. I can't grasp real necessity of passing all the
append_rel_list during flattening of an union all leaf subquery. No one
can reference this leaf, isn't it?
After
I wrote:
> Richard Guo writes:
>> I noticed we also check 'parse->hasSubLinks' when we fix PHVs and
>> AppendRelInfos in pull_up_simple_subquery. I'm not sure why we have
>> this check. It seems not necessary.
> Yeah, I was wondering about that too ... maybe it was important
> in some previous
Richard Guo writes:
> I noticed we also check 'parse->hasSubLinks' when we fix PHVs and
> AppendRelInfos in pull_up_simple_subquery. I'm not sure why we have
> this check. It seems not necessary.
Yeah, I was wondering about that too ... maybe it was important
in some previous state of the
On Thu, Dec 22, 2022 at 9:50 AM Tom Lane wrote:
> Andrey Lepikhov writes:
> > Superficial study revealed possibly unnecessary operations that could be
> > avoided:
> > 1. Walking across a query by calling substitute_phv_relids() even if
> > lastPHId shows that no one phv is presented.
>
> Yeah,
Andrey Lepikhov writes:
> Complaint is about auto-generated query with 1E4 simple union all's (see
> t.sh to generate a demo script). The reason: in REL_11_STABLE it is
> planned and executed in a second, but REL_12_STABLE and beyond makes
> matters worse: planning of such a query needs tons
Hi,
Client report on a corner case have shown up possible minor
non-optimality in procedure of transformation of simple UNION ALL
statement tree.
Complaint is about auto-generated query with 1E4 simple union all's (see
t.sh to generate a demo script). The reason: in REL_11_STABLE it is
