Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists
Дата
Msg-id CAMkU=1znqF6_NRHOHHZ=Uv+20QNEcNj7GMcO-hmB9Y1efCJKdw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On Thu, Nov 10, 2016 at 7:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
otar shavadze <oshavadze@gmail.com> writes:
>> Hmmm ... actually, I wonder if maybe '@>' here is the contrib/intarray
>> operator not the core operator?  The intarray operator didn't get plugged
>> into any real estimation logic until 9.6.

> So, you mean that better would be go to version 9.6 ?

If you are using that contrib module, and it's capturing this operator
reference, that would probably explain the bad estimate.  You could
drop the extension if you're not depending on its other features, or you
could explicitly qualify the operator name ("operator(pg_catalog.@>)"),
or you could upgrade to 9.6 (don't forget to do ALTER EXTENSION ... UPDATE
afterwards).

Isn't the operator determined at index build time?  If he doesn't want to update to 9.6, I think he would need to rebuild the index, removing the "gin__int_ops" specification.

Cheers,

Jeff

В списке pgsql-general по дате отправления:

Предыдущее
От: Kim Rose Carlsen
Дата:
Сообщение: Re: How to hint 2 coulms IS NOT DISTINCT FROM each other
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists