I wrote:
> Richard Guo writes:
>> So it seems that we need to do nullingrel adjustments in a more common
>> place.
> I agree: this suggests that we fixed it in the wrong place.
So pursuant to that, 0001 attached reverts the code changes from bfd332b3f
and 63e4f13d2 (keeping the test cases and so
Richard Guo writes:
> I just realized that we may still have holes in this area. Until now
> we're mainly focusing on LATERAL subquery, in which case the lateral
> reference Vars are copied into rel->subplan_params and we've already
> adjusted the nulling bitmaps there. But what about the latera
hard to
compose a query for each of the other 4 cases that shows that we need to
adjust the nulling bitmaps for them too.
1. RTE_RELATION with tablesample
explain (costs off)
select * from int8_tbl t1
left join int8_tbl t2 on true
left join lateral
(select * from int8_tbl t3 TABLESAMPLE
I wrote:
> Richard Guo writes:
>> Oh, wait ... It occurred to me that we may have this same issue with
>> Memoize cache keys.
> Good catch --- I'll take a closer look tomorrow.
Pushed after a little more fiddling with the comments.
regards, tom lane
Richard Guo writes:
> Oh, wait ... It occurred to me that we may have this same issue with
> Memoize cache keys. In get_memoize_path we collect the cache keys from
> innerpath's ppi_clauses and innerrel's lateral_vars, and the latter may
> contain nullingrel markers that need adjustment. As an e
On Mon, Jun 12, 2023 at 10:02 PM Tom Lane wrote:
> Richard Guo writes:
> > Yeah, that makes sense. process_subquery_nestloop_params is a better
> > place to do this adjustments. +1 to v2 patch.
>
> Pushed, then.
Oh, wait ... It occurred to me that we may have this same issue with
Memoize cac
Richard Guo writes:
> Yeah, that makes sense. process_subquery_nestloop_params is a better
> place to do this adjustments. +1 to v2 patch.
Pushed, then.
regards, tom lane
On Sat, Jun 10, 2023 at 12:08 AM Tom Lane wrote:
> Richard Guo writes:
> > We can identify in which form of identity 3 the plan is built up by
> > checking the relids of the B/C join's outer rel. If it's in the first
> > form, the outer rel's relids must contain the A/B join. Otherwise it
> >
Richard Guo writes:
> On Wed, May 31, 2023 at 10:47 AM Richard Guo wrote:
>> When we transform the first form of identity 3 to the second form, we've
>> converted Pb*c to Pbc in deconstruct_distribute_oj_quals. But we
>> neglect to consider that rel C might be a RTE_SUBQUERY and contains
>> qual
> On 31.05.2023, at 08:36, Richard Guo wrote:
>
> Attached is a patch for that. Does this make sense?
>
> Thanks
> Richard
>
All I can say is that it fixes the error for me — also for the non-simplified
original query that I have.
-markus
t; n INTEGER
>> );
>>
>> SELECT *
>> FROM (VALUES (1)) t(c)
>> LEFT JOIN t ljl1 ON true
>> LEFT JOIN LATERAL (WITH cte AS (SELECT * FROM t WHERE t.n = ljl1.n)
>> SELECT * FROM cte) ljl2 ON ljl1.n = 1;
>>
>> ERROR: wrong varnullingrel
N t ljl1 ON true
> LEFT JOIN LATERAL (WITH cte AS (SELECT * FROM t WHERE t.n = ljl1.n)
> SELECT * FROM cte) ljl2 ON ljl1.n = 1;
>
> ERROR: wrong varnullingrels (b 3) (expected (b)) for Var 2/1
>
> Note that the error does **not** occur if the CTE is unwrapped like this:
>
> SE
) ljl2 ON ljl1.n = 1;
ERROR: wrong varnullingrels (b 3) (expected (b)) for Var 2/1
Note that the error does **not** occur if the CTE is unwrapped like this:
SELECT *
FROM (VALUES (1)) t(c)
LEFT JOIN t ljl1 ON true
LEFT JOIN LATERAL (SELECT * FROM t WHERE t.n = ljl1.n) ljl2 ON ljl1.n = 1
13 matches
Mail list logo
