I wrote:
> Robert Haas writes:
>> But we could also find some way to assert that the parameterization
>> sets contain only top-most rels.
> Hmm ... perhaps worth doing. I think bms_is_subset against
> all_baserels would work.
[ tries that ... ] Nope, it needs to be all_query_rels. I plead
ENO
Robert Haas writes:
> On Mon, Jan 8, 2024 at 5:39 PM Tom Lane wrote:
>> I think we're talking at cross-purposes. What I was wondering about
>> (at least further down in the thread) was whether we shouldn't be
>> checking *both* the "real" and the "parent" relids to make sure they
>> don't overla
On Mon, Jan 8, 2024 at 5:39 PM Tom Lane wrote:
> I think we're talking at cross-purposes. What I was wondering about
> (at least further down in the thread) was whether we shouldn't be
> checking *both* the "real" and the "parent" relids to make sure they
> don't overlap the parameterization sets
Robert Haas writes:
> On Sat, Jan 6, 2024 at 4:08 PM Tom Lane wrote:
>> The argument for the patch as proposed is that we should make the
>> mergejoin and hashjoin code paths do what the nestloop path is doing.
>> However, as I replied further down in that other thread, I'm not
>> exactly convinc
On Sat, Jan 6, 2024 at 4:08 PM Tom Lane wrote:
> > Well, this explanation made sense to me:
> > https://www.postgresql.org/message-id/CAMbWs4-%2BGs0HJ9ouBUb%3DqwHsGCXxG%2B92eJzLOpCkedvgtOWQ%3DQ%40mail.gmail.com
>
> The argument for the patch as proposed is that we should make the
> mergejoin and h
Robert Haas writes:
> On Fri, Jan 5, 2024 at 4:36 PM Tom Lane wrote:
>> I don't think I believe this code change, let alone any of the
>> explanations for it. The point of these Asserts is to be sure that
>> we don't form an alleged parameterization set that includes any rels
>> that are include
On Fri, Jan 5, 2024 at 4:36 PM Tom Lane wrote:
> I don't think I believe this code change, let alone any of the
> explanations for it. The point of these Asserts is to be sure that
> we don't form an alleged parameterization set that includes any rels
> that are included in the new join, because
Robert Haas writes:
> On Fri, Nov 3, 2023 at 2:47 AM Richard Guo wrote:
>> Comment is now added above the Asserts. Thanks for taking an interest
>> in this.
> I'd like to suggest rewording this comment a little more. Here's my proposal:
> Both of the paths passed to this function are still par
On Fri, Nov 3, 2023 at 2:47 AM Richard Guo wrote:
> Comment is now added above the Asserts. Thanks for taking an interest
> in this.
I'd like to suggest rewording this comment a little more. Here's my proposal:
Both of the paths passed to this function are still parameterized by
the topmost par
I have reviewed the changes and it looks fine.
The new status of this patch is: Ready for Committer
On Thu, Sep 7, 2023 at 11:09 PM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Probably it's just because of my limited experience with the optimizer
> but I don't find the proposed change particularly straightforward. I
> would suggest adding a comment before the Assert's and/or a detai
Hi Richard,
> As stated in [1], all paths arriving here are parameterized by top
> parents, so we should check against top_parent_relids if it exists in
> the two Asserts.
>
> Attached is a patch fixing that.
Probably it's just because of my limited experience with the optimizer
but I don't find
12 matches
Mail list logo
