Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists
В списке pgsql-general по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists |
| Дата | |
| Msg-id | 5308.1478790672@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists (otar shavadze <oshavadze@gmail.com>) |
| Ответы |
Re: Gin indexes on intarray is fast when value in array
does not exists, and slow, when value exists
|
| Список | pgsql-general |
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).
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера