Andrew Gierth schrieb am 28.02.2019 um 10:29:
> [intarray woes]
>
> Thomas> Is this expected behaviour? Is this caused by the Postgres core
> Thomas> (e.g. the optimizer to taking the opclass into account) or is
> Thomas> it a "problem" in the way the intarray module defines its
> Thomas> operators?
>
> It's basically a conflict between intarray (which is historically older)
> and the built-in array indexing support.
>
> The reason it happens is that the operator resolution logic matches an
> (integer[] && integer[]) operator in preference to (anyarray && anyarray)
> regardless of their relative position on the search_path. This
> resolution happens before anything is known about any indexes that might
> be applicable. Then later, at planning time, an index is chosen based on
> the operator, not the reverse.
That makes sense, thanks.