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.
