MIME-Version: 1.0
References: <582986626.20241129201134@dima.nikitin.name>
In-Reply-To: <582986626.20241129201134@dima.nikitin.name>
From: Junwang Zhao <zhjwpku@gmail.com>
Date: Sat, 30 Nov 2024 19:54:35 +0800
Message-ID: <CAEG8a3L_4WJk7bHy7Lzy540Biqp=HZry1ghmgMVymOFkJrP2Dw@mail.gmail.com>
Subject: Re: Unclear code - please elaborate
To: Dmitry Nikitin <pgsql-hackers@dima.nikitin.name>
Cc: pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAEG8a3L_4WJk7bHy7Lzy540Biqp%3DHZry1ghmgMVymOFkJrP2Dw%40mail.gmail.com>
Precedence: bulk

On Sat, Nov 30, 2024 at 4:15=E2=80=AFPM Dmitry Nikitin
<pgsql-hackers@dima.nikitin.name> wrote:
>
> Hello ,
>
>   https://github.com/postgres/postgres/blob/5d39becf8ba0080c98fee4b635755=
52f6800b012/src/backend/optimizer/prep/prepjointree.c#L3856
> bms_next_member() is allowed to return the zero as a valid value. Subsequ=
ent rt_fetch() offsets that
> zero to -1 which leads to the assertion down the code. Nothing wrong here=
? Either zero is simply not
> possible after that bms_next_member() because of some factors behind the =
code?
>

rtindex 0 is not used, see the logic of setup_simple_rel_arrays and the com=
ments
of PlannerInfo.simple_rel_array.

/*
* simple_rel_array holds pointers to "base rels" and "other rels" (see
* comments for RelOptInfo for more info). It is indexed by rangetable
* index (so entry 0 is always wasted). Entries can be NULL when an RTE
* does not correspond to a base relation, such as a join RTE or an
* unreferenced view RTE; or if the RelOptInfo hasn't been made yet.
*/

>
> --
> Best regards,
>  Dmitry                          mailto:pgsql-hackers@dima.nikitin.name
>
>
>


--=20
Regards
Junwang Zhao