On Fri, Jun 30, 2023 at 11:00 PM Tom Lane wrote:
> Richard Guo writes:
> > I think it just makes these two assertions meaningless to skip it for
> > non-nestloop joins if the input paths are for otherrels, because paths
> > would never be parameterized by the member relations. So these two
> >
Richard Guo writes:
> On Fri, Jun 30, 2023 at 12:20 AM Tom Lane wrote:
>> Yeah, while looking at this I was wondering why try_mergejoin_path and
>> try_hashjoin_path don't do the same "Paths are parameterized by
>> top-level parents, so run parameterization tests on the parent relids"
>> dance th
On Fri, Jun 30, 2023 at 12:20 AM Tom Lane wrote:
> Richard Guo writes:
> > On Wed, Jun 28, 2023 at 10:09 PM Tom Lane wrote:
> >> Those cases will go through calc_non_nestloop_required_outer
> >> which has
> >> /* neither path can require rels from the other */
> >> Assert(!bms_overlap(outer_par
On Fri, Jun 30, 2023 at 12:16 AM Tom Lane wrote:
> Pushed with that and defenses added to try_mergejoin_path and
> try_hashjoin_path. It looks like the various try_partial_xxx_path
> functions already reject cases that could be problematic. (They
> will not accept inner parameterization that wo
Richard Guo writes:
> On Wed, Jun 28, 2023 at 10:09 PM Tom Lane wrote:
>> Those cases will go through calc_non_nestloop_required_outer
>> which has
>> /* neither path can require rels from the other */
>> Assert(!bms_overlap(outer_paramrels, inner_path->parent->relids));
>> Assert(!bms_overlap(in
Richard Guo writes:
> BTW, it seems that extra->sjinfo would always have a valid value here.
> So maybe we do not need to check if it is not NULL explicitly?
Right, I was being conservative but this module expects that to
always be provided.
Pushed with that and defenses added to try_mergejoin_p
On Wed, Jun 28, 2023 at 10:09 PM Tom Lane wrote:
> Those cases will go through calc_non_nestloop_required_outer
> which has
>
> /* neither path can require rels from the other */
> Assert(!bms_overlap(outer_paramrels, inner_path->parent->relids));
> Assert(!bms_overlap(inn
On Thu, Jun 29, 2023 at 10:39 AM Richard Guo wrote:
> On Wed, Jun 28, 2023 at 10:09 PM Tom Lane wrote:
>
>> However, given that what we need is to exclude parameterization
>> that depends on the currently-formed OJ, it seems to me we can do
>> it more simply and without any new JoinPathExtraData
On Wed, Jun 28, 2023 at 10:09 PM Tom Lane wrote:
> However, given that what we need is to exclude parameterization
> that depends on the currently-formed OJ, it seems to me we can do
> it more simply and without any new JoinPathExtraData field,
> as attached. What do you think?
I think it make
Richard Guo writes:
> On Wed, Jun 28, 2023 at 6:28 AM Tom Lane wrote:
>> For a real fix, I'm inclined to extend the loop that calculates
>> param_source_rels (in add_paths_to_joinrel) so that it also tracks
>> a set of incompatible relids that *must not* be present in the
>> parameterization of a
On Wed, Jun 28, 2023 at 6:28 AM Tom Lane wrote:
> For a real fix, I'm inclined to extend the loop that calculates
> param_source_rels (in add_paths_to_joinrel) so that it also tracks
> a set of incompatible relids that *must not* be present in the
> parameterization of a proposed path. This woul
On Tue, Jun 27, 2023 at 10:12 PM Tom Lane wrote:
> Richard Guo writes:
> > That's right. This issue has something to do with the
> > outer-join-aware-Var changes. I reduced the repro to the query below.
>
> Thanks for the simplified test case.
>
> > When joining s1/t3 to t4, the relid of outer
I wrote:
> So it looks to me like something further up should have rejected this
> path as not being usable here. Not sure what's dropping the ball.
After further digging, I've concluded that what usually stops us
from generating this bogus path for the t3/t4 join is the
"param_source_rels" heuri
Richard Guo writes:
> That's right. This issue has something to do with the
> outer-join-aware-Var changes. I reduced the repro to the query below.
Thanks for the simplified test case.
> When joining s1/t3 to t4, the relid of outer join t3/t4 appears both in
> the joinrel's relids and in the j
On Tue, Jun 27, 2023 at 1:35 PM Michael Paquier wrote:
> On Mon, Jun 26, 2023 at 11:05:43PM -0500, Jaime Casanova wrote:
> > The attached query makes beta2 crash with attached backtrace.
> > Interestingly the index on ref_6 is needed to make it crash, without
> > it the query works fine.
>
> Issu
On Mon, Jun 26, 2023 at 11:05:43PM -0500, Jaime Casanova wrote:
> The attached query makes beta2 crash with attached backtrace.
> Interestingly the index on ref_6 is needed to make it crash, without
> it the query works fine.
Issue reproduced here. I am adding an open item, whose owner should
be
Hi,
The attached query makes beta2 crash with attached backtrace.
Interestingly the index on ref_6 is needed to make it crash, without
it the query works fine.
--
Jaime Casanova
Director de Servicios Profesionales
SYSTEMGUARDS - Consultores de PostgreSQL
#0 __GI_raise (sig=sig@entry=6) at ../sy
17 matches
Mail list logo
