Re: missing indexes in indexlist with partitioned tables - Mailing list pgsql-hackers

From Amit Langote
Subject Re: missing indexes in indexlist with partitioned tables
Date
Msg-id CA+HiwqEm-u7s42MgyJvKfE0CKAQ8XThVOi6b2n8LoqGvfbvr7w@mail.gmail.com
Whole thread Raw
In response to Re: missing indexes in indexlist with partitioned tables  (Arne Roland <A.Roland@index.de>)
Responses Re: missing indexes in indexlist with partitioned tables
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: make MaxBackends available in _PG_init
Next
From: David Rowley
Date:
Subject: Re: Fix BUG #17335: Duplicate result rows in Gather node