Re: Partitioned tables and covering indexes
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Teodor Sigaev <teodor@sigaev.ru>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Alexander Korotkov <a.korotkov@postgrespro.ru>, Jaime Casanova <jaime.casanova@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-11T19:47:53Z
Lists: 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
Commits
-
Fix interference between covering indexes and partitioned tables
- 524054598fd3 11.0 landed
-
Cleanup covering infrastructure
- c266ed31a8a3 11.0 landed
-
Rename IndexInfo.ii_KeyAttrNumbers array
- c9c875a28fa6 11.0 landed