Sorry I didn't make myself clear. By "different content via s2->p" I
mean different content than what came before, not than s1->p. There was
issue caused by such modifications reported before in [1]. In that
case, the problematic query is
explain (costs off)
select * from t t1
inner join t t2 on t1.a = t2.a
left join t t3 on t1.b > 1 and t1.b < 2;
The 'required_relids' in the two RestrictInfos for 't1.b > 1' and 't1.b
< 2' both reference the same bitmapset. The content of this bitmapset
is {t1, t3}. However, as we have decided to remove the t1/t2 join by
eliminating t1, we need to substitute the Vars of t1 with the Vars of
t2. To achieve this, we remove each of the two RestrictInfos from the
joininfo lists it is in and perform the necessary replacements.
After applying this process to the first RestrictInfo, the bitmapset now
becomes {t2, t3}. Consequently, the second RestrictInfo also perceives
{t2, t3} as its required_relids. As a result, when attempting to remove
it from the joininfo lists, a problem arises, because it is not in t2's
joininfo list.
Just to clarify, I am not objecting to your v2 patch. I just want to
make sure what is our purpose in introducing REALLOCATE_BITMAPSETS. I'd
like to confirm whether our intention aligns with the former scenario or
the latter one that I mentioned upthread.
Also, here are some review comments for the v2 patch:
* There is no reallocation that happens in bms_add_members(), do we need
to call bms_copy_and_free() there?
* Do you think we can add Assert(bms_is_valid_set(a)) for bms_free()?
[1]
https://www.postgresql.org/message-id/flat/CAMbWs4_wJthNtYBL%2BSsebpgF-5L2r5zFFk6xYbS0A78GKOTFHw%40mail.gmail.comThanks
Richard
