Re: Partitioned tables and covering indexes

On Wed, Apr 11, 2018 at 10:47 PM, Alvaro Herrera <alvherre@alvh.no-ip.org>
wrote:

> Teodor Sigaev wrote:
>
> > Patch attached.
>
> I wonder why this is a problem in opfamilies but not collations.
> If we don't compare collations, wouldn't it make more sense to break out
> of the loop once the number of keys is reached?
>

It appears that INCLUDE columns might have collation defined.
For instance, following query is working:

create index t_s1_s2_idx on t (s1) include (s2 collate "en_US.UTF-8");

However, I don't see any point in defining collations here, because
INCLUDE attributes exist solely for index-only scans.  So, index just
can return value of INCLUDE attribute "as is", no point to do something
with collation.

So, I propose to disable collations for INCLUDE attributes.

When this code was written, there was no question as to what length the
> opfamilies/collations the arrays were; it was obvious that they must be
> of the length of the index attributes.  It's not obvious now.  Maybe add
> a comment about that?
>

In b3b7f789 Tom have resized one array size from total number of
attributes to number of key attributes.  And I like idea of applying the
same to all other array: make them sized to total number of attributes
with filling of absent attributes with 0.


> > But it seems to me, field's names of
> > IndexInfo structure are a bit confused now:
> >     int         ii_NumIndexAttrs;   /* total number of columns in index
> */
> >     int         ii_NumIndexKeyAttrs;    /* number of key columns in
> index */
> >     AttrNumber  ii_KeyAttrNumbers[INDEX_MAX_KEYS];
> >
> > ii_KeyAttrNumbers contains all columns, i.e. it contains ii_NumIndexAttrs
> > number of columns, not a ii_NumIndexKeyAttrs number as easy to think.
> >
> > I suggest rename ii_KeyAttrNumbers to ii_AttrNumbers or
> ii_IndexAttrNumbers.
> > Opinions?
>
> Yeah, the current situation seems very odd.
>

+1 for ii_IndexAttrNumbers.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company