Pull to refresh

Comments 21

Может быть вы знаете, как у Postgres обстоят дела с поиском вхождения строки, т.е. если бы вы в вашем примере искали «tain Ne»?
Не слишком круто, но кое-что есть:
www.depesz.com/2011/02/19/waiting-for-9-1-faster-likeilike
Для словарного и префиксного поиска есть лучшие решения:
stackoverflow.com/questions/17633344/is-there-a-way-to-index-in-postgres-for-fast-substring-searches

Впрочем, задача ускорения поиска по подстроке сама по себе не имеет, видимо, эффективного решения.
Впрочем, задача ускорения поиска по подстроке сама по себе не имеет, видимо, эффективного решения.

Я пока к такому же выводу пришел.
Есть префиксные деревья, которые могут помочь решить эту задачу.
а ещё есть gist_trgm_ops он же может матчинг с регулярками ускорять
про это первая ссылка galaxy. В текущей реализации у них ограничени на длину строки.
Отличная статья. А можете пояснить, каким образом в узле может закончиться место? Есть какие-то ограничения постгреса на размер узла?
Обычно размер узла подбирается так, чтобы он был равен одной странице ввода/вывода(или нескольким 2/4/8).
Для того, чтобы выяснить, как работает B-Tree индекс, вовсе не обязательно погружаться по локоть в исходные коды. Ожидал какого-то более существенного срыва покровов.
Следует уточнить, что для индексов используются не то что понимается под B-tree, а B* или B+ -tree. В обычных B-tree информация может храниться в узлах дерева, а в B+ — только в листьях, что дает некоторый простор для оптимизаций.
-Но затем по необъяснимой причине Postgres продолжил сканировать всю базу, сравнивая каждое значение с искомым, хотя оно уже было найдено!

ожидал услышать ответ на этот вопрос, ведь вы покопались в исходниках… а вы покопались в исходниках и открыли америку
Ответ мне кажется очевидным, там же стоит сортировка по полю id, а это значит, что (поскольку значения name не уникальны, ведь никто не сказал обратного) даже когда мы нашли запись, удовлетворяющую условию, то это вовсе не значит, что мы нашли запись с минимальным id (поскольку нам также никто не сказал, что мы просматриваем id в нужном порядке — по возрастанию).
Твою дивизию ) А я уж думал, Tom Lane где-то exit for пропустил ))
На всякий случай замечу, что это перевод :)
Потому, что запрос выглядит как «дай мне всех пользователей с именем таким-то». Нигде не говорится, что такое имя единственно. Limit применяется уже к результату выборки и на время работы запроса не влияет.
Не скажите. Если бы не было order by, было бы логично после нахождения первых N совпадений поиск прекращать…
Это все, конечно, хорошо (почти хорошо, см. выше коммент про сортировку по id), но такими темпами придется очень долго исследовать то, что у Постгресса под капотом…
>> Индексы — один из самых мощных инструментов в реляционных базах данных.

Строго говоря индексы к реляционной модели данных никакого отношения не имеют.
Индексы это способ ускорить обработку данных.
Прекрасное издание Жюля Верна с отличными иллюстрациями, простите за офтоп.
Я правильно понял, что «поиск последовательностей» это перевед сочетания «sequential scan»? Если да, то по-русски это называется «последовательный перебор» или «последовательный просмотр»
Sign up to leave a comment.