Yep, honestly this is far beyond my knowledge. On Wed, Mar 13, 2019 at 2:56 PM Corey Huinker <corey.huin...@gmail.com> wrote:
> On Wed, Mar 13, 2019 at 5:11 AM Flo Rance <troura...@gmail.com> wrote: > >> It is an expected behavior. You can see the list of array operators with >> which a GIN index can be used in the doc: >> >> https://www.postgresql.org/docs/current/indexes-types.html >> >> And a very good and detailed explanation about any operator here: >> >> >> https://stackoverflow.com/questions/4058731/can-postgresql-index-array-columns/29245753#29245753 >> >> Regards, >> Flo >> >> On Wed, Mar 13, 2019 at 2:44 AM Corey Huinker <corey.huin...@gmail.com> >> wrote: >> >>> A client had an issue with a where that had a where clause something >>> like this: >>> >>> WHERE 123456 = ANY(integer_array_column) >>> >>> >>> I was surprised that this didn't use the pre-existing GIN index on >>> integer_array_column, whereas recoding as >>> >>> WHERE ARRAY[123456] <@ integer_array_column >>> >>> >>> did cause the GIN index to be used. Is this a known/expected behavior? >>> If so, is there any logical reason why we couldn't have the planner pick up >>> on that? >>> >> > Thanks. I'll bring the question of why-cant-we over to the hackers list. > > >
