Hi, On Mon, Jan 24, 2022 at 9:30 PM Arne Roland <a.rol...@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 partitioned index), 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't have 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
