From: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Overloaded && operator from intarray module prevents index usage. |
Date: | 2019-02-28 10:22:33 |
Message-ID: | 95eb0be2-6020-3197-ecdb-8850f691ffa5@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Morris de Oryx | 2019-02-28 11:02:11 | Re: crosstab function |
Previous Message | Andrew Gierth | 2019-02-28 09:29:03 | Re: Overloaded && operator from intarray module prevents index usage. |