|
|
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
Тестируем PostgreSQL 9.4 на предмет возможности использования в проекте в качестве альтернативного бесплатного сервера. Сразу скажу, что Постгрес я вижу всего вторую неделю. Но для принятия решения собственно углубляться в него или нет нужны хоть какие-то обоснования его приемлемости для нашей задачи кроме аргумента, что тупо бесплатно. Короче потестировал его на простенькой базе в которой всего ~ 1,5 ляма записей в табличке. Табличка типа: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Поле ph_Name2 (citext) просто дублирует данные из ph_Name эксперимента ради. Индексы по полям имен имеются. Хотя, судя по планам запросов не похоже, что они имеют какое-либо значение в данном случае. Ну а далее простой запрос: Код: plsql 1. 2. 3. 4. Результат по всем Михайловым и пр. выдан за 1022 ms, что в общем-то терпимо. Единственное, что несколько смущает - это стабильно одинаковый результат при любых последующих повторениях запроса, что как бы говорит об отсутствии кэширования. Но! поскольку есть большая необходимость искать без учета регистра, то ищем по нижнему регистру: Код: plsql 1. 2. 3. 4. Результат 2236 ms В два раза хуже OK Пробуем ILIKE вместо LIKE: Код: plsql 1. 2. 3. 4. Результат 3200 ms В три раза хуже Последняя попытка поиск по citext полю: Код: plsql 1. 2. 3. 4. Результат 3310 ms Худший результат Для сравнения MSSQL на ровно той же машине и такой же базе и с Case Insensative collation ( без учета регистра ) на том же запросе выдает 903ms на "непрогретом" кэше и всего 240ms на "прогретом". В связи с этим, PostgreSQL-гуру, пожалуйста, расскажите / подскажите, чего бы еще можно подкрутить / повертеть в PostgreSQL, чтобы немного улучшить результаты поиска без учета регистра? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 01:39 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 02:15 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
Leonid, сделайте: Код: sql 1. и покажите план (explain (analyze, buffers)) второго запроса. судя по времени выполнения имеющиеся индексы сейчас вообще не используются (или по полтаблицы выбирается). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 06:46 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
LeonidРезультат 2236 ms В два раза хуже полагаю и количество строк поболе. Если нужна только кириллица, то используй БД с однобайтовой кодировкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 09:27 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
Leonid... Но для принятия решения собственно углубляться в него или нет нужны... Нет нужды. Оставайтесь там, где Вы есть. Для начала расскажите: - где стоит PostgreSQL (если на винде - то это ой!) - какие настройки сервера выполнены (если оставлено по умолчанию - это ой!) - какие усилия были предприняты для ускорения выполнения тестового запроса? Все ли возможности задействованы? Магии не существует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 09:31 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
AlexiusLeonid, сделайте: Код: sql 1. О! Спасибо! До тонкостей типа "Operator Classes" в индексах я без Вас еще не скоро бы добрался. Т.е. если я правильно понимаю, то в Постгресе всегда нужно штамповать 2 индекса по текстовому полю, если есть желание искать как по равенству так и по LIKE с начала строки. Т.е. в моем примере: Код: plsql 1. 2. 3. Время запроса сократилось на приемлемые 600ms благодаря этому индексу. Спасибо за дельный совет! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 10:10 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
ursidoLeonid... Но для принятия решения собственно углубляться в него или нет нужны... Нет нужды. Оставайтесь там, где Вы есть. Знаете сильно чем отличаются русскоязычные профессиональные форумы от интернациональных ( преимущественно англоязычных )? А вот как раз наличием на русскоязычных форумах таких как у Вас "пустых пожеланий" не по делу ;) Лично я бы и не менял MSSQL. Там и так все без танцев с бубном зачастую работает быстро и годами без особых вопросов . Но кризис на дворе и все такое... Клиенты прижиместей становятся и на лицензии их жаба душит. ursidoДля начала расскажите: - где стоит PostgreSQL (если на винде - то это ой!) - какие настройки сервера выполнены (если оставлено по умолчанию - это ой!) - какие усилия были предприняты для ускорения выполнения тестового запроса? Все ли возможности задействованы? Магии не существует. Стоит на Винде и стоять там и будет. Ни на какие Линуксы переписывать сервисы и прочее мы пока не собираемся. Настройками сервера играли при помощи PgTune. Похоже, что разница пока не большая, но под серьезной нагрузкой будет видно. Но моего вопроса это не слишком касается. По поводу же вопроса уже четко и без вашей общей пурги объяснил Alexius. За что ему еще раз спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 10:30 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
LeonidПо поводу же вопроса уже четко и без вашей общей пурги объяснил Alexius. За что ему еще раз спасибо! Вы заблуждаетесь. Предыдущий оратор предложил частный случай какого-то действия без каких-либо объяснений. Вы бездумно собезьянничали, затем сделали странный вывод (то самое "всегда"). Из двух представленных индексов - один лишний. Будет лежать мертвым грузом. Почему - вот здесь и начинается разнообразная пурга, которая Вам ни к чему. Ну и в продолжение аномалий: почему-то задействован тип citext, а вот триграммные индексы никакого интереса не вызвали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 10:56 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
ursidoВы заблуждаетесь. Предыдущий оратор предложил частный случай какого-то действия без каких-либо объяснений. Вы бездумно собезьянничали, затем сделали странный вывод (то самое "всегда"). Из двух представленных индексов - один лишний. Будет лежать мертвым грузом. Почему - вот здесь и начинается разнообразная пурга, которая Вам ни к чему. Ну и в продолжение аномалий: почему-то задействован тип citext, а вот триграммные индексы никакого интереса не вызвали. Предыдущий оратор в отличии от Вас предложил очень дельный совет, который работает и дает результат. Я не уверен по поводу необходимости индекса без varchar_pattern_ops. Может быть он и не нужен. Но я читаю оригинальную документацию, где написано: http://www.postgresql.org/docs/9.4/static/indexes-opclass.html Note that you should also create an index with the default operator class if you want queries involving ordinary <, <=, >, or >= comparisons to use an index. Such queries cannot use the xxx_pattern_ops operator classes. Если у Вас есть что возразить по этому поводу, то рад буду выслушать. Естественно, без пурги про "если на винде - то это ой!" или о том, что где-то нужно оставаться ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 11:21 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
Leonid, Да-да! Все именно так. Теперь осталось только рассмотреть случай, при котором будут использоваться операции "<, <=, >, or >=" по текстовому полю при работе конкретного приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 11:49 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
ursidoLeonid, Да-да! Все именно так. Теперь осталось только рассмотреть случай, при котором будут использоваться операции "<, <=, >, or >=" по текстовому полю при работе конкретного приложения. легко. выборки по диапазонам. вообще обычный индекс [хенджобом] вы легко используете как варчар--паттерн--опс (за этот опс, вместо реализации лайка на обычном индексе убивать вообще-то надо. это так, к слову. костыль же явный) -- диапазонной техникой. А вот обратное -- вам недоступно. Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 12:00 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
qwwqursidoLeonid, Да-да! Все именно так. Теперь осталось только рассмотреть случай, при котором будут использоваться операции "<, <=, >, or >=" по текстовому полю при работе конкретного приложения. легко. выборки по диапазонам. вообще обычный индекс [хенджобом] вы легко используете как варчар--паттерн--опс (за этот опс, вместо реализации лайка на обычном индексе убивать вообще-то надо. это так, к слову. костыль же явный) -- диапазонной техникой. А вот обратное -- вам недоступно. Код: sql 1. 2. 3. 4. 5. 6. 7. как -то сразу отказалась демонстрироваться. поправил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 12:03 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
qwwq, Раз. Засчитали. Теперь нужно определиться, используется ли этот случай в конкретном приложении. Кстати, какой индекс будет использоваться при WHERE "ph_Name" SIMILAR TO 'Михайло(в|г)%' Отличается ли постановка задачи (кроме сортировки) от Вашей исходной? Я предполагаю, что индекс с text_pattern_ops будет задействован. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 12:31 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
qwwqлегко. выборки по диапазонам... Да, спасибо. Правда для случая case insensitive это будет Код: plsql 1. 2. 3. 4. 5. И это как раз использует индекс без opc. К слову сказать, даже на ~10-20ms быстрее работает. Но все же синтаксис менее читаемый, чуть хуже переносимый и более баго-возможный. Но выходит, что индекс без opc все же нужно держать для возможных сравнений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 12:48 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
Leonid, я это не к тому, что так делать надо в sql--коде. а к тому, что вместо "каждому оператору--свой индекс", как повелось, разрабам надо было честно расписать использование обычного индекса и для лайк (similar to) тоже -- нет никаких алгоритмических проблем, чтобы держать по 2 одинаковые вспомогательные структуры данных , вместо одной. Всем прочим, кроме постгреса, вот как-то без этих опсов всё удаётся. Да и мне на коленке собрать запрос для постгреса, пользующий обычный индекс -- тоже. А планировщику -- повторить мою коленку -- нет. "не шмогла", типа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 12:59 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
qwwq...вместо "каждому оператору--свой индекс", как повелось, разрабам надо было честно расписать использование обычного индекса и для лайк (similar to) тоже Да, это первый из известных мне серверов БД, в котором приходится так геморроиться с индексами для like. И у MS и в Оракле все как-то проще. Но да что поделаешь? Главное, что в результате все же можно как-то разрулить созданием специфического индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2015, 13:13 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
Leonidqwwq...вместо "каждому оператору--свой индекс", как повелось, разрабам надо было честно расписать использование обычного индекса и для лайк (similar to) тоже Да, это первый из известных мне серверов БД, в котором приходится так геморроиться с индексами для like. И у MS и в Оракле все как-то проще. Но да что поделаешь? Главное, что в результате все же можно как-то разрулить созданием специфического индекса. может тебе надо в этом поле колейшен сделать регистронезависимый? тогда никаких танцев с индексами, не надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2015, 12:45 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
Ivan Durakможет тебе надо в этом поле колейшен сделать регистронезависимый? тогда никаких танцев с индексами, не надо.А ты знаешь как сделать в Постгресе колейшен регистронезависимым? Если знаешь, то расскажи как. Это у Мелкомягких все просто. Задал, например, Cyrillic_General_CI_AS при создании базы или поля и радуйся. А если Cyrillic_General_CI_AI то даже "ёжик" и "Ежик" сойдутся. У Постгреса такого разнообразия не видно. Во всяком случае по умолчанию. Только default, C и POSIX. А еще есть citext колонки. IMHO Проще уж доп.индекс по lower с классом varchar_pattern_ops построить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2015, 15:07 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2015, 10:18 |
|
||
|
Как еще ускорить case insensitive поиск?
|
|||
|---|---|---|---|
|
#18+
LeonidIvan Durakможет тебе надо в этом поле колейшен сделать регистронезависимый? тогда никаких танцев с индексами, не надо.А ты знаешь как сделать в Постгресе колейшен регистронезависимым? Если знаешь, то расскажи как. Это у Мелкомягких все просто. Задал, например, Cyrillic_General_CI_AS при создании базы или поля и радуйся. А если Cyrillic_General_CI_AI то даже "ёжик" и "Ежик" сойдутся. У Постгреса такого разнообразия не видно. Во всяком случае по умолчанию. Только default, C и POSIX. А еще есть citext колонки. IMHO Проще уж доп.индекс по lower с классом varchar_pattern_ops построить. ну на линухе в нем полно колейшенов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2015, 11:22 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39094366&tid=1997657]: |
0ms |
get settings: |
8ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
27ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 197ms |
| total: | 292ms |

| 0 / 0 |
