From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: int2vector and btree indexes |
Date: | 2016-10-12 02:32:06 |
Message-ID: | 5fad635f-92a2-413e-ac08-40195d94628a@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016/10/11 21:40, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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
Attachment | Content-Type | Size |
---|---|---|
rm-int2vector-op-hash-infra-1.patch | text/x-diff | 7.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2016-10-12 02:34:38 | Re: buildfarm client release 4.18 |
Previous Message | Tom Lane | 2016-10-12 00:51:09 | Re: buildfarm client release 4.18 |