Re: Partitioned tables and covering indexes

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Partitioned tables and covering indexes
Дата
Msg-id CAH2-Wzkdg_StJuH9MtiiYA=WyJDk_1S2ZVtSPQz73hkKgBz2sQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Partitioned tables and covering indexes  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: Partitioned tables and covering indexes  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
On Wed, Apr 11, 2018 at 1:58 PM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> 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.

Hmm. I'm not sure that that's exactly the right thing to do. We seem
to want to have case-insensitive collations in the future. The fact
that you can spell out collation name in ON CONFLICT's unique index
inference specification suggests this, for example. I think that a
collation is theoretically allowed to affect the behavior of equality,
even though so far we've never tried to make that work for any
collatable datatype.

Maybe the right thing to do is to say that any collation will work
equally well (as will any opclass). Maybe that's the same thing as
what you said, though.

> +1 for ii_IndexAttrNumbers.

+1

-- 
Peter Geoghegan


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Creation of wiki page for open items of v11
Следующее
От: Keith Fiske
Дата:
Сообщение: Re: Native partitioning tablespace inheritance