MIME-Version: 1.0
References: <CACJufxFVQmr4=JWHAOSLuKA5Zy9H26nY6tVrRFBOekHoALyCkQ@mail.gmail.com>
 <CAApHDvpBMSGhXVeFdw_qmjPqU5yHvJJ7k0z7kD069EC4di2Pag@mail.gmail.com>
 <CAMbWs4-iYKxrMs8kj+49gVA4X1_=PYAaw5HL_3g_yVXpAHzYww@mail.gmail.com>
 <1e6ca7b3-98e6-46b2-9982-97f92c7523d8@dunslane.net> <76910.1715106055@sss.pgh.pa.us>
 <CAApHDvoR9cXHb_+j7j8=zBty35B8z22SX51cZN7ZRf+QTPJ1fA@mail.gmail.com>
 <276516.1715121616@sss.pgh.pa.us> <CAApHDvrvcJd2DCAV0vDKmRxp5tvXq3=+RwhRns4OjoHQ1UbDEg@mail.gmail.com>
 <279607.1715122556@sss.pgh.pa.us> <CAApHDvqRgYq8yL3GUj-1z2xPv6cLy7D4tjxhhijWnsHLOSukLg@mail.gmail.com>
 <282081.1715123889@sss.pgh.pa.us> <815049.1715192644@sss.pgh.pa.us>
 <CAApHDvp5Az4MA3r1REaV=NyTF=30qNhe+N=OWb5g_edAvS+rCA@mail.gmail.com> <936562.1715208033@sss.pgh.pa.us>
In-Reply-To: <936562.1715208033@sss.pgh.pa.us>
From: Richard Guo <guofenglinux@gmail.com>
Date: Thu, 9 May 2024 10:43:31 +0800
Message-ID: <CAMbWs49fy=f-jCd7s33d9AGjnYZn6R8TEDU6armi7Yo6QHCKiw@mail.gmail.com>
Subject: Re: Revert: Remove useless self-joins *and* -DREALLOCATE_BITMAPSETS
 make server crash, regress test fail.
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, 
	jian he <jian.universality@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000240fb80617fc630e"
Archived-At: <https://www.postgresql.org/message-id/CAMbWs49fy%3Df-jCd7s33d9AGjnYZn6R8TEDU6armi7Yo6QHCKiw%40mail.gmail.com>
Precedence: bulk

--000000000000240fb80617fc630e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 9, 2024 at 6:40=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> David Rowley <dgrowleyml@gmail.com> writes:
> > I'm fine with this one as it's the same as what I already mentioned
> > earlier.  I had imagined doing bms_del_member(bms_copy ... but maybe
> > the compiler is able to optimise away the additional store. Likely, it
> > does not matter much as pallocing memory likely adds far more overhead
> > anyway.
>
> I actually wrote it that way to start with, but undid it after
> noticing that the existing code in remove_rel_from_restrictinfo
> does it in separate steps, and thinking that that was good for
> both separation of concerns and a cleaner git history.  I too
> can't believe that an extra fetch will be noticeable compared
> to the cost of the adjacent bms_xxx operations.


I also think it seems better to do bms_copy in separate steps, not only
because this keeps consistent with the existing code in
remove_rel_from_restrictinfo, but also because we need to do
bms_del_member twice for each lefthand/righthand relid set.

Speaking of consistency, do you think it would improve the code's
readability if we rearrange the code in remove_rel_from_query so that
the modifications of the same relid set are grouped together, just like
what we do in remove_rel_from_restrictinfo?  I mean something like:

   sjinf->min_lefthand =3D bms_copy(sjinf->min_lefthand);
   sjinf->min_lefthand =3D bms_del_member(sjinf->min_lefthand, relid);
   sjinf->min_lefthand =3D bms_del_member(sjinf->min_lefthand, ojrelid);

   ...

Thanks
Richard

--000000000000240fb80617fc630e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Thu, May 9, 2024 at 6:40=E2=80=AFAM To=
m Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">David Rowl=
ey &lt;<a href=3D"mailto:dgrowleyml@gmail.com" target=3D"_blank">dgrowleyml=
@gmail.com</a>&gt; writes:<br>
&gt; I&#39;m fine with this one as it&#39;s the same as what I already ment=
ioned<br>
&gt; earlier.=C2=A0 I had imagined doing bms_del_member(bms_copy ... but ma=
ybe<br>
&gt; the compiler is able to optimise away the additional store. Likely, it=
<br>
&gt; does not matter much as pallocing memory likely adds far more overhead=
<br>
&gt; anyway.<br>
<br>
I actually wrote it that way to start with, but undid it after<br>
noticing that the existing code in remove_rel_from_restrictinfo<br>
does it in separate steps, and thinking that that was good for<br>
both separation of concerns and a cleaner git history.=C2=A0 I too<br>
can&#39;t believe that an extra fetch will be noticeable compared<br>
to the cost of the adjacent bms_xxx operations.</blockquote><div><br></div>=
<div>I also think it seems better to do bms_copy in separate steps, not onl=
y<br>because this keeps consistent with the existing code in<br>remove_rel_=
from_restrictinfo, but also because we need to do<br>bms_del_member twice f=
or each lefthand/righthand relid set.<br><br>Speaking of consistency, do yo=
u think it would improve the code&#39;s<br>readability if we rearrange the =
code in remove_rel_from_query so that<br>the modifications of the same reli=
d set are grouped together, just like<br>what we do in remove_rel_from_rest=
rictinfo?=C2=A0 I mean something like:<br><br>=C2=A0 =C2=A0sjinf-&gt;min_le=
fthand =3D bms_copy(sjinf-&gt;min_lefthand);<br>=C2=A0 =C2=A0sjinf-&gt;min_=
lefthand =3D bms_del_member(sjinf-&gt;min_lefthand, relid);<br>=C2=A0 =C2=
=A0sjinf-&gt;min_lefthand =3D bms_del_member(sjinf-&gt;min_lefthand, ojreli=
d);<br><br>=C2=A0 =C2=A0...<br><br>Thanks<br>Richard<br></div></div></div>

--000000000000240fb80617fc630e--