On Fri, Jun 9, 2023 at 5:13 AM Tom Lane wrote:
> Richard Guo writes:
> > Hmm, maybe we can additionally check if the PHV needs to be evaluated
> > above the join. If so it cannot be removed.
> Yeah, that seems to make sense, and it squares with the existing
> comment saying that PHVs used
Richard Guo writes:
> On Tue, May 30, 2023 at 10:28 AM Richard Guo wrote:
>> I haven't thought through how to fix it, but I suspect that we may need
>> to do more checking before we decide to remove PHVs in
>> remove_rel_from_query.
Oh, I like this example! It shows a place where we are now
On Tue, May 30, 2023 at 10:28 AM Richard Guo wrote:
> I haven't thought through how to fix it, but I suspect that we may need
> to do more checking before we decide to remove PHVs in
> remove_rel_from_query.
>
Hmm, maybe we can additionally check if the PHV needs to be evaluated
above the join.
On Sat, May 27, 2023 at 12:16 AM Tom Lane wrote:
> Ah. I realized that we could make the problem testable by adding
> assertions that a joinclause we're not removing doesn't contain
> any surviving references to the target rel or join. That turns
> out to fire (without the bug fix) in half a
Richard Guo writes:
> On Fri, May 26, 2023 at 6:06 AM Tom Lane wrote:
>> Based on what deconstruct_distribute_oj_quals is doing, it seems
>> likely to me that there are cases that require ignoring
>> commute_above_r, but I've not tried to devise one. It'd be good to
>> have one to include in
On Fri, May 26, 2023 at 6:06 AM Tom Lane wrote:
> 1. The test case you give upthread only needs to ignore commute_below_l,
> that is it still passes without the lines
>
> +join_plus_commute = bms_add_members(join_plus_commute,
> +
> removable_sjinfo->commute_above_r);
>
> Based on what
Richard Guo writes:
> On Wed, May 24, 2023 at 2:48 AM Tom Lane wrote:
>> I wonder if we could do something involving recording the
>> rinfo_serial numbers of all the clauses extracted from a particular
>> syntactic join level (we could keep this in a bitmapset attached
>> to each
On Wed, May 24, 2023 at 2:48 AM Tom Lane wrote:
> Richard Guo writes:
> > Considering that clone clauses should always be outer-join clauses not
> > filter clauses, I'm wondering if we can add an additional check for that
> > in RINFO_IS_PUSHED_DOWN, something like
>
> > #define
Richard Guo writes:
>> create table t (a int unique, b int);
>>
>> explain (costs off)
>> select 1 from t t1
>> left join t t2 on true
>> inner join t t3 on true
>> left join t t4 on t2.a = t4.a and t2.a = t3.a;
>> ERROR: no relation entry for
t; left join t t4 on t2.a = t4.a and t2.a = t3.a;
> ERROR: no relation entry for relid 6
>
> I looked into it and it should be caused by some problem in outer-join
> removal. After we've decided that the join to t4 is removable, which is
> no problem, one of the things we need to d
I came across $subject on master and here is the query I'm running.
create table t (a int unique, b int);
explain (costs off)
select 1 from t t1
left join t t2 on true
inner join t t3 on true
left join t t4 on t2.a = t4.a and t2.a = t3.a;
ERROR: no relation entry for relid 6
I
11 matches
Mail list logo
