Привет
> Возможно из за этого прогнозное время отличается от реального на два порядка?
Что такое "прогнозное время"?
Планировщик не прогнозирует время выполнения запроса. План выбирается с минимальной оценённой стоимостью выполнения, но
этоне время.
> 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.
Сергей