Re: Partitioned tables and covering indexes - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Partitioned tables and covering indexes
Date
Msg-id 20180411194753.vhnwqss2hgqtao6v@alvherre.pgsql
Whole thread Raw
In response to Re: Partitioned tables and covering indexes  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: Partitioned tables and covering indexes
List pgsql-hackers
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?

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?

> 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.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: Partitioned tables and covering indexes
Next
From: Andrew Gierth
Date:
Subject: Re: lazy detoasting