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
