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