Re: Partitioned tables and covering indexes

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Partitioned tables and covering indexes
Date: 2018-04-11 20:58:00
Message-ID: CAPpHfds2etOsc-YSu+TKn05099wJrZPDg8yMhE460X3O6Zpaig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 11, 2018 at 10:47 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-04-11 20:58:55 Re: Creation of wiki page for open items of v11
Previous Message Thomas Munro 2018-04-11 20:56:13 Re: es_query_dsa is broken