кстати у GIN индекса есть одна мелкая, но интересная особенность относительно b-tree даже если использовать расширение b-tree для скалярных типов в GIN'е.
В двух словах: GIN требует приведения типов четкого и если он создавался с bigint, то надо в явном виде указывать ::bigint, в то время как b-tree индекс обычный такого не требует.
Сорри за небольшой оффтоп, но я не могу задать в первой статье вопрос. Я так понимаю, что обновление индексируемой колонки все таки не пересобирает partial indexes, которые не попадают под изменение?
иначе было бы крайне грустно для частичных индексов.
Спасибо. Так понятно почему распарсинга повторного не происходит.
Да это ввело меня в заблуждение :(.
Но я так понимаю, если мы используем Gist который Lossy, перепроверка будет происходить всегда, и повторный распарсинг тоже будет происходить всегда?
Также вы в статье привели пример поиска редкого и частого слова в одном запросе, т.е. гипотетически такие сочетания могут привести, к тому что при неудачных сочетаниях лексем проверка начнет требовать повторного разбора вектора. Это может быть незаметно на маленьких body, но если там примерно такого размера посты как этот, разница станет достаточно заметной, даже если таких проверок надо будет проводить немного.
PS Спасибо за хорошую серию. Статью про GIN ждал с интересом.
вы неверно поняли мой вопрос. вы привели в комментарии два примера на поиск, в одном было условие наличия где-то в теле письма слов hello и hackers, во втором фразы hello hackers. В первом случае hello & hackers вы получили практически одинаковые результаты по времени в случае когда tsv хранится в таблице и когда он вычисляется налету.
а во втором случае при поиске по фразе вы получили ожидаемое замедление в случае генерации tsv на лету.
Вопрос: что не так с вариантом hello & hackers, почему вариант с хранением результата не вынес в одну калитку вариант с вычислением на лету?
У меня есть предположение, что тут где-то вмешался кеш, если бы вы вывели не только потраченное время, но еще и ожидаемую оценку, это могло бы проясниться.
вопрос: а почему в случае hello & hackers результат вышел по времени одинаковый, а в случае с поиском по фразе разный? и там, и там был Recheck Condition, и там и там по идее должно было распарсить plain_body для того, чтобы проверить условие.
LIKE an apple-pie ORDER BY или второй способ поломать работу с индексами.
В вашем примере слома не произойдет, он касается varchar_pattern_ops :)) потому что там операторы ~<~, ~>~ и пр.
я про нее сделал кратенькую заметочку Yo-ho and a bottle of GIN
В двух словах: GIN требует приведения типов четкого и если он создавался с bigint, то надо в явном виде указывать ::bigint, в то время как b-tree индекс обычный такого не требует.
иначе было бы крайне грустно для частичных индексов.
Да это ввело меня в заблуждение :(.
Но я так понимаю, если мы используем Gist который Lossy, перепроверка будет происходить всегда, и повторный распарсинг тоже будет происходить всегда?
Также вы в статье привели пример поиска редкого и частого слова в одном запросе, т.е. гипотетически такие сочетания могут привести, к тому что при неудачных сочетаниях лексем проверка начнет требовать повторного разбора вектора. Это может быть незаметно на маленьких body, но если там примерно такого размера посты как этот, разница станет достаточно заметной, даже если таких проверок надо будет проводить немного.
PS Спасибо за хорошую серию. Статью про GIN ждал с интересом.
а во втором случае при поиске по фразе вы получили ожидаемое замедление в случае генерации tsv на лету.
Вопрос: что не так с вариантом hello & hackers, почему вариант с хранением результата не вынес в одну калитку вариант с вычислением на лету?
У меня есть предположение, что тут где-то вмешался кеш, если бы вы вывели не только потраченное время, но еще и ожидаемую оценку, это могло бы проясниться.