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.

Сергей