On 20/2/2024 17:43, David Rowley wrote:
On Tue, 20 Feb 2024 at 22:57, Andrei Lepikhov wrote:
I agree that it would be nice to teach the planner how to do this, but
I think it just has to be a cost-based decision. Imagine how the
transformed query would perform of pg_am had a billion rows and
p
On Tue, 20 Feb 2024 at 22:57, Andrei Lepikhov wrote:
> explain (costs off)
> SELECT relname FROM pg_class c1
> WHERE relname = ANY (
>SELECT a.amname from pg_am a WHERE a.oid=c1.oid GROUP BY a.amname
> );
>
> We see on master:
> Nested Loop
> -> Seq Scan on pg_class c1
> -> Subquer
On 1/9/2022 19:24, Richard Guo wrote:
Even if we ignore these assertion checks, in the final plan we would
have to access the RHS of the B/C semi join, i.e. C, to evaluate qual
'c.j = a.j' at the join level of A/BC join, which is wrong.
Having committed 9f13376396 recently, we did a lot of work i
On Wed, Oct 5, 2022 at 4:38 AM Andrey Lepikhov
wrote:
> On 5/10/2022 02:45, Zhihong Yu wrote:
> > Hi,
> > For contain_placeholders():
> >
> > + if (IsA(node, Query))
> > + return query_tree_walker((Query *) node, contain_placeholders,
> > context, 0);
> > + else if (IsA(node, PlaceHolde
On 5/10/2022 02:45, Zhihong Yu wrote:
Hi,
For contain_placeholders():
+ if (IsA(node, Query))
+ return query_tree_walker((Query *) node, contain_placeholders,
context, 0);
+ else if (IsA(node, PlaceHolderVar))
Fixed
The `else` is not needed.
For correlated_t struct, it would be b
Hi,
For contain_placeholders():
+ if (IsA(node, Query))
+ return query_tree_walker((Query *) node, contain_placeholders,
context, 0);
+ else if (IsA(node, PlaceHolderVar))
The `else` is not needed.
For correlated_t struct, it would be better if the fields have comments.
+
On 9/13/22 16:40, Andrey Lepikhov wrote:
On 5/9/2022 12:22, Richard Guo wrote:
On Fri, Sep 2, 2022 at 7:09 PM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
To resolve both issues, lower outer join passes through pull_sublinks_*
into flattening routine (see attachment).
I've added t
On 5/9/2022 12:22, Richard Guo wrote:
On Fri, Sep 2, 2022 at 7:09 PM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
> Hmm, I'm not sure this patch works correctly in all cases. It
seems to
> me this patch pulls up the subquery without checking the constraints
> im
On 9/5/22 12:22, Richard Guo wrote:
On Fri, Sep 2, 2022 at 7:09 PM Andrey Lepikhov
Yeah, it's not easy-to-solve problem. If I correctly understand the
code, to fix this problem we must implement the same logic, as
pull_up_subqueries (lowest_outer_join/safe_upper_varnos).
Yeah, I
On Fri, Sep 2, 2022 at 7:09 PM Andrey Lepikhov
wrote:
> On 9/1/22 17:24, Richard Guo wrote:
> > On Wed, Aug 31, 2022 at 2:35 PM Andrey Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > Before flattening procedure we just look through the quals of
> subquery,
> > pull to the upper
On 9/1/22 17:24, Richard Guo wrote:
On Wed, Aug 31, 2022 at 2:35 PM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
Before flattening procedure we just look through the quals of subquery,
pull to the upper level OpExpr's containing variables from the upper
relation and r
On Wed, Aug 31, 2022 at 2:35 PM Andrey Lepikhov
wrote:
> Before flattening procedure we just look through the quals of subquery,
> pull to the upper level OpExpr's containing variables from the upper
> relation and replace their positions in the quals with true expression.
> Further, the flatteni
Hi,
One of the most annoying things in the planner for me is unnesting of
correlated queries [1]. A number papers on this subject were published
starting 1980s, but only trivial optimizations exists in the Core. It
means a lack of performance, especially when we use foreign tables in
subquery
13 matches
Mail list logo
