Amit Langote <langote_amit...@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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
