Re: int2vector and btree indexes

On 2016/10/11 21:40, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
>> I was wrong that the index *never* gets used.  It does in fact get used if
>> the operator is an ordering search operator (<, <=, >, >=), in which case
>> the query would use an array_ops operator (which is a btree operator class
>> for type anyarray) and hence matches the index operator family.  I failed
>> to mention in my original message that int2vector_ops is a hash operator
>> class.  There is exactly one =(int2vector, int2vector) operator in the
>> system of which there is no btree equivalent.
>
> Hmm ... I kind of wonder why we have int2vectoreq or hashint2vector at
> all, likewise the hash opclass based on them.  The code says that they
> are needed to support catcache index columns, but the only columns of
> this type are
>
> regression=# select attrelid::regclass,attname from pg_attribute where atttypid = 'int2vector'::regtype;
>   attrelid  |  attname
> ------------+-----------
>  pg_index   | indkey
>  pg_index   | indoption
>  pg_trigger | tgattr
> (3 rows)
>
> and those don't have indexes at all, let alone catcaches based on them.
> So it looks to me like we could remove this infrastructure.  There is
> value in being able to hash int2vectors during queries, for sure, but
> we could let that be done by the anyarray hash opclass.

Agreed.  So how about the attached patch to remove the said infrastructure?

> Having said that, int2vector is not meant as a user-facing type and so
> I don't particularly care whether indexes built on it work conveniently.
> But it looks to me like we've got some unnecessary code here.

Ah, I did wonder whether int2vector has been deprecated as a user-facing
type.  Anyway after applying the patch, it seems that the original
complaint I raised is no longer an issue (or so I think) - operators
applied to int2vector are always resolved to those accepting anyarray and
matched with anyarray_ops of the correct index access method.

Thanks,
Amit