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 | 1458.1478646305@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | 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:
> " -> Bitmap Index Scan on idx (cost=0.00..23.80 rows=533
> width=0) (actual time=35.054..35.054 rows=90052 loops=1)"
> " Index Cond: (my_array @> '{8}'::integer[])"
Seems like your problem here is that the planner has no idea about the
selectivity of this condition --- if it did, I think it would have
made the right choice, because it would have made a much higher estimate
for the cost of the indexscan.
AFAICT, Postgres 9.5 does make a reasonably correct guess when given
up-to-date stats. I speculate that you need to ANALYZE this table.
If there are a lot of distinct possible values in the arrays, increasing
the statistics target for the column might be needed.
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера