Возможно это нормально

Думаю что на database encoding выбраный в верхней строчке 1251 в collation не повлияет

Доброго времени суток! Нужна помощь с JSON, не скупитесь ссылками на доку поскольку я самостоятельно попытался найти ответ в сети, но так и не нашел. SELECT row_to_json(t1), row_to_json(t2) INTO _ t1, _t2 FROM t1 LEFT JOIN t2 ON t2.id = t1.user_id WHERE t1.company_id = 1 ORDER BY t1.id DESC LIMIT 1; Как из переменной _t1 выбрать значение колонки title?

Доброго времени суток! Нужна помощь с JSON, не скупитесь ссылками на доку поскольку я самостоятельно попытался найти ответ в сети, но так и не нашел. SELECT row_to_json(t1), row_to_json(t2) INTO _ t1, _t2 FROM t1 LEFT JOIN t2 ON t2.id = t1.user_id WHERE t1.company_id = 1 ORDER BY t1.id DESC LIMIT 1; Как из переменной _t1 выбрать значение колонки title?

так ведь есть оператор: t1->'title'

Без плана - это гадание на кофейной гущи)

вот планы для случая, когда фамилия + имя и фамилия + имя + отчество - https://pastebin.com/Ayth6y8F

так ведь есть оператор: t1->'title'

Пробовал, выдает ошибку: ОШИБКА: оператор не существует: json <> unknown LINE 1: SELECT (t1->'type_col' <> 'blocked' AND _ca...

<> смени оператор на OR

вот планы для случая, когда фамилия + имя и фамилия + имя + отчество - https://pastebin.com/Ayth6y8F

Bitmap INDEX Scan ON fullname_fuzzy_idx (COST=0.00..320.33 ROWS=577 width=0) (actual TIME=235.448..235.448 ROWS=13807 loops=1) Много читаем по индексу. А какое значение pg_trgm.similarity_threshold?

вот планы для случая, когда фамилия + имя и фамилия + имя + отчество - https://pastebin.com/Ayth6y8F

А если построить GIST индекс в дополнение или вместо GIN ?

<> смени оператор на OR

я проверяю на неравенство

я проверяю на неравенство

ок, тогда на !=

А если построить GIST индекс в дополнение или вместо GIN ?

Вроде GIN должен быть побыстрее по идее?

ок, тогда на !=

Не работает, та же ошибка

Вроде GIN должен быть побыстрее по идее?

А ты проверь. Я не знаю, какой результат ты получишь. Мне любопытно.

А если построить GIST индекс в дополнение или вместо GIN ?

я пробовал гист, там все намного хуже

А ты проверь. Я не знаю, какой результат ты получишь. Мне любопытно.

к сожалению у меня нет исходных данных)

Ну вот и проверили :-)

Bitmap INDEX Scan ON fullname_fuzzy_idx (COST=0.00..320.33 ROWS=577 width=0) (actual TIME=235.448..235.448 ROWS=13807 loops=1) Много читаем по индексу. А какое значение pg_trgm.similarity_threshold?

стоит стандартный 0.3.

Учитывая механизм работы триграмм и GIN, замедление при более длинном запросе ожидаемо.

да, я понимаю. вот и интересовался альтернативными практиками/грязными хаками

Не работает, та же ошибка

все, решил проблему записал значение в переменную

А если попробовать использовать полнотескстовый поиск + триграммы?

да, я понимаю. вот и интересовался альтернативными практиками/грязными хаками

Сделать полнотекстовый поиск с сортировкой по ревалентности?

разве это решит проблему очепяток?

:-) у нам примерно одинаковая с Вадимом мысль.

разве это решит проблему очепяток?

Если слов 3, то есть вероятность, что два из них более менее точные

А если попробовать использовать полнотескстовый поиск + триграммы?

а можно подробнее мысль?

то есть полнотекстовый поиск - это преобразование слов в лексемы по определенным словарям. нечеткий поиск - это опечатки. а что мне даст нечеткие лексемы? или я не понимаю идею?

https://postgrespro.ru/docs/postgrespro/9.6/pgtrgm есть блок F.41.5. Интеграция с текстовым поиском

https://postgrespro.ru/docs/postgrespro/9.6/pgtrgm есть блок F.41.5. Интеграция с текстовым поиском

Клево!

да, здорово! но разве это мой случай? да, я погу согласно пункту 41.5 искать лексемы с очепятками и не париться за словоформы (окончания и т.д)... но у меня другая проблема, производительность. как добавление лексем ускорит результаты?

Привет, есть у кого опыт успешной миграции с MySQL каким-нибудь тулом?

да, здорово! но разве это мой случай? да, я погу согласно пункту 41.5 искать лексемы с очепятками и не париться за словоформы (окончания и т.д)... но у меня другая проблема, производительность. как добавление лексем ускорит результаты?

Проблема с производительностью из за того, что слишком много триграмм удовлетворяют условиям поиска и попадают в индекс - 13807. И потом делается вот это ROWS Removed BY INDEX RECHECK: 13492. То есть сканируем то, что нам не нужно в большом количестве. Если искать сначала полнотестом целые слова (и хотя бы одно из них будет без опечаток), а потом уже искать триграммы, то это должно ускорить процесс поиска

N-граммы надо с N=5-6 =)

О, Стас подключился)

N-граммы надо с N=5-6 =)

А такие в природе водятся?) Я встречал только 2-3...

Проблема с производительностью из за того, что слишком много триграмм удовлетворяют условиям поиска и попадают в индекс - 13807. И потом делается вот это ROWS Removed BY INDEX RECHECK: 13492. То есть сканируем то, что нам не нужно в большом количестве. Если искать сначала полнотестом целые слова (и хотя бы одно из них будет без опечаток), а потом уже искать триграммы, то это должно ускорить процесс поиска

Хорошо, понял вашу мысль. Проверю завтра

Хорошо, понял вашу мысль. Проверю завтра

? ждем результатов. Интересно)

А такие в природе водятся?) Я встречал только 2-3...

Вообще да, но в данный момент в pg_trgm только 3

Вообще да, но в данный момент в pg_trgm только 3

Я правильно понял, что речь идёт про отдельные реализации под конкретных заказчиков от PostgresPro?)

не, для постгреса я не слышал что бы кто-то это делал

я встречал standalone самодельный индексер с бОльшими N

Mysql умеет ngram для n от 1 до 10

Подскажите - где почитать как правильно трактовать cost в explain?

http://www.dalibo.org/_media/understanding_explain.pdf

Mysql умеет ngram для n от 1 до 10

Кстати, прикольно сделано. Парсер парсит в н-граммы, а дальше обычный фуллтекст

Да. Я тестировал на простых примерах - работает

Прикольно.

Кстати, в постгресе достаточно было бы сделать полнотекстовый словарь для этого.

+1 задачка для стажёров

Угу, словарь бы генерил нграммы

Причём его можно объявлять с параметром n если ни че не путаю

Да, у словарей есть параметры. Я бы сделал параметрами n, lpadding и rpadding.

У меня, кстати, лежит модуль vgram, написанный ещё в аспирантские годы.

Нигде не публиковал пока.

Основная порочность у него – он ожидает, что частоты n-gram глобальны и лежат в строго определённой табличке.

Умеет пока только LIKE/ILIKE, но остальному можно научить.

Привет, по mySQL вопросы принимаются?

если нет, дайте группу где принимаются

Просто нашел только эту

@mysql_ru

пасиб

Умеет пока только LIKE/ILIKE, но остальному можно научить.

А можно его взять попробовать? Я бы отписался сюда по сравнению производительности поиска для разных n

OK, я выложу на github и отпишу сюда.

Спасибо!

@darthunix а если заюзать отдельное решение для поиска типа эластик серча?

@darthunix а если заюзать отдельное решение для поиска типа эластик серча?

Только как самый крайний случай - хотелось бы все же решить проблему средствами postgresql.

Данных много?

Около 400к записей (ФИО). Сейчас пробую вариант составить список уникальных лексем из ФИО, и в каждой записи с ФИО хранить ссылки на составляющие его лексемы. А по лексемам делать нечеткий поиск триграммами

@darthunix а если заюзать отдельное решение для поиска типа эластик серча?

не уверен что его стоит вообще юзать... для полнотекста есть решения лучше (это если не брать в расчёт ПГ)

ES требует несколько нод для нормальной работы, кучу оперативки и ещё куча подводных камней с этими их индексами

не спорю, можно получше найти, но 400к записей имхо мало, я думал там больше

это ~1.2кк строк - можно все в оперативу засунуть и не кашлять

не спорю, можно получше найти, но 400к записей имхо мало, я думал там больше

Именно поэтому я и хочу решить средствами pg. Ну и был удивлён низкой скоростью при решении влоб

к слову в постгресе нету 2Н грамм... те что актуальны для японского языка.

т.е. из коробки поиск в постгресе не применим к японскому :(

Ну поэтому японцы и сделали себе биграммное расширение

Ну поэтому японцы и сделали себе биграммное расширение

их даже несколько

но все они out of tree

даже в contrib не пробили

Много хороших расширений ставятся отдельно, это не страшно

@darthunix а если попытаться переложить поиск с базы на приложение? я думаю куча есть либ для нечеткого поиска

интересно георапределённый постгресс делал кто?

@darthunix а если попытаться переложить поиск с базы на приложение? я думаю куча есть либ для нечеткого поиска

нет желания тащить эти 400к в приложение и поддерживать в согласованном состоянии с бд. я лучше добью оптимизацию сейчас по нечеткому поиску в pg, чем подпишусь на эти увлекательные приключения

аналог rack3 у cassandra для postgre никто ещё не придумал?

интересно георапределённый постгресс делал кто?

а при потере связи какое ожидаемое поведение?

а при потере связи какое ожидаемое поведение?

работать с теми что в связи для приложения при возобновлении сравнить дарнные и самые новые взять как нужное

а при потере связи какое ожидаемое поведение?

есть 3 дц, надо чтобы при потере 2 из них всё ещё работало

а приложение даже не узнало, что те 2 дц потеряны

при возобновлении связи, с хоста где более свежие записи 2 других или 1 берёт данные себе обновлённые

я помню гугл решал такие вопросы атомными часами в каждом дц и уникальным ключом был временной тик

я помню гугл решал такие вопросы атомными часами в каждом дц и уникальным ключом был временной тик

?ну фнс не гугл