Re: GIN indexes on an = ANY(array) clause

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: GIN indexes on an = ANY(array) clause
Date: 2019-03-14 15:11:17
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 3/13/19 5:38 PM, Tom Lane wrote:
> regression=# select amopopr::regoperator from pg_amop where amopfamily = 2745;
> amopopr
> -----------------------
> &&(anyarray,anyarray)
> @>(anyarray,anyarray)
> <@(anyarray,anyarray)
> =(anyarray,anyarray)
> (4 rows)
> and none of those are obviously related to the =(int4,int4) operator that
> is in the ScalarArrayOp. The only way to get from point A to point B is
> to know very specifically that =(anyarray,anyarray) is related to any
> scalar-type btree equality operator, which is not the kind of thing the
> GIN AM ought to know either.

In the discussions for the patch for foreign keys from arrays[1] some
people proposed add a new operator, <<@(anyelement,anyarray), to avoid
having to construct left hand side arrays. Would that help here or does
it still have the same issues?



In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2019-03-14 15:26:20 Re: Offline enabling/disabling of data checksums
Previous Message Amit Langote 2019-03-14 15:06:34 Re: [sqlsmith] Failed assertion at relnode.c