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
theindex scan will return all the entries that pass the scan key, plus possibly additional entries that do not. The
coresystem's index-scan machinery will then apply the index conditions again to the heap tuple to verify whether or not
itreally should be selected. If the recheck option is not specified, the index scan must return exactly the set of
matchingentries.
 

То есть индекс имеет право вернуть не только строго подходящие 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 - не всегда.