Hi,
On Mon, Jan 24, 2022 at 9:30 PM Arne Roland <A.Roland@index.de> wrote:
> The comment at my end goes on:
>
> /*
> * Don't add partitioned indexes to the indexlist, since they are
> * not usable by the executor. If they are unique add them to the
> * partindexlist instead, to use for further pruning. If they
> * aren't that either, simply skip them.
> */
"partindexlist" really made me think about a list of "partial indexes"
for some reason. I think maybe "partedindexlist" is what you are
looking for; "parted" is commonly used as short for "partitioned" when
naming variables.
The comment only mentions "further pruning" as to what partitioned
indexes are to be remembered in RelOptInfo, but it's not clear what
that means. It may help to be more specific.
Finally, I don't understand why we need a separate field to store
indexes found in partitioned base relations. AFAICS, nothing but the
sites you are interested in (relation_has_unique_index_for() and
rel_supports_distinctness()) would ever bother to look at a
partitioned base relation's indexlist. Do you think putting them into
in indexlist might break something?
> Regarding the semantics: This is sort of what the statement checks for (skip for inhparent, if not unique or not
partitionedindex), i.e. it checks for the case, where the index shouldn't be added to either list.
>
> Side note: I personally think the name inhparent is mildly confusing, since it's not really about inheritance. I
don'thave a significantly better idea though.
Partitioned tables are "inheritance parent", so share the same code as
what traditional inheritance parents have always used for planning.
--
Amit Langote
EDB: http://www.enterprisedb.com