Re: GIN индекс по JSONB и Recheck

Привет

> Возможно из за этого прогнозное время отличается от реального на два порядка?

Что такое "прогнозное время"?
Планировщик не прогнозирует время выполнения запроса. План выбирается с минимальной оценённой стоимостью выполнения, но это не время.

> 1. Можно ли избавиться от Recheck по jsonb - GIN индексу

Нет. Recheck тут не только от gin, но и от bitmap.

> 2. Если нет - можно ли избавиться от Recheck Removed хотя бы?

При обходе bitmap индекс сам может запросить recheck значения, если реализация этого ops считает, это значение подойти под условие может, но не обязательно.

> 3. Если смотреть на оба EXPLAIN то можно видеть что в обоих случаях выбираются ВСЕ совпадения индекса (в БД на 20 млн записей содержится ровно 37 записей удовлетворяющих поисковому запросу). Вопрос: можно ли перестроить запрос чтобы выбиралось не более LIMIT записей? Или поясните - почему так происходит и как с этим жить?

Потому что это Bitmap Index Scan. Index Scan по GIN невозможен, amgettuple не представлен.

> Ну а поскольку запрос - поисковый, то могут запросить как нечто хорошо селективное, так и нечто слабо селективное. То есть если он будет в промежутке выбирать скажем из 10 млн записей 1 млн а потом от него брать LIMIT 10 - то это будет непорядок.

Тут можно gin_fuzzy_search_limit покрутить - как раз верхний лимит результата для GIN.

Сергей