From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Flo Rance <trourance(at)gmail(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Planner not choosing GIN index |
Date: | 2019-03-13 13:55:49 |
Message-ID: | CADkLM=d1qUY_MtvRgMW=nVy9iRGMZ24KHbcLxqSdfqdo6gY3HQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Mar 13, 2019 at 5:11 AM Flo Rance <trourance(at)gmail(dot)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(dot)huinker(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Flo Rance | 2019-03-13 14:20:02 | Re: Planner not choosing GIN index |
Previous Message | Mariel Cherkassky | 2019-03-13 12:59:23 | Re: ERROR: found xmin from before relfrozenxid |