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

Привет

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

recheck тут появляется из двух мест:
- от bitmap index scan сам по себе. Может проверять и отбрасывать много строк, если становится непример lossy вместо exact. (недостаток work_mem в частности, ну это так, для полноты ответа)
- если индекс при добавлении элемента в bitmap сказал, что не уверен в истинности этого значения.

В мануале про второй случай сказано в частности здесь: https://www.postgresql.org/docs/current/index-scanning.html

> The access method can report that the index is lossy, or requires rechecks, for a particular query. This implies that the index scan will return all the entries that pass the scan key, plus possibly additional entries that do not. The core system's index-scan machinery will then apply the index conditions again to the heap tuple to verify whether or not it really should be selected. If the recheck option is not specified, the index scan must return exactly the set of matching entries.

То есть индекс имеет право вернуть не только строго подходящие TID, но и те, которые возможно подходят, но надо перепроверить. Вот неподходящие как раз и будет видно в Recheck Removed.

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

Это лучше в -hackers уже спрашивать.
По идее amgettuple реализовать можно, но вот смысла в этом немного намой взгляд. По gin невозможно делать сортировку. А запрос без сортировки вида "точность не надо, N каких-то достаточно" - штука редкая и для него уже есть gin_fuzzy_search_limit.

>> Нет. Recheck тут не только от gin, но и от bitmap.
>>
>>> 2. Если нет - можно ли избавиться от Recheck Removed хотя бы?
>>
>> При обходе bitmap индекс сам может запросить recheck значения, если реализация этого ops считает, это значение подойти под условие может, но не обязательно.
>
> я тогда не понимаю. Поскольку индекс в случае текстов ВСЕГДА выдает recheck
> Recheck в случае текстов ВСЕГДА делает множество Recheck Removed (даже когда TEXT[] просто индексируем)

Removed - не всегда.