а какая причина отказа от сфинкса?

рассматривал вариант убрать дополнительный компонент в системе, если в postgres все хорошо работает

рассматривал вариант убрать дополнительный компонент в системе, если в postgres все хорошо работает

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

а почему? Проблема в скорости или в качестве?

Разработчик русскоязычный. Все другие аналогичные движки норм по английскому языку работают, а русский никому не нужен

Все, кто работал с такими движками подтвердят, что для русского только сфинск

ну нет конечно, эластик тоже нормально работает с русским языком

ну нет конечно, эластик тоже нормально работает с русским языком

Подтверждаю

ребят, подскажите, где можно про full text search почитать исчерпывающее руководство для начинающих? Хочется отказаться от shpinx и пользоваться встроеным механизмом поиска в postgres

на счет полноты не уверен http://www.sai.msu.su/~megera/postgres/talks/fts_pgsql_intro.html

каким способом быстрее делать выборки, через курсоры ("FETCH ...") или через "SELECT ... OFFSET ... LIMIT ..."?

Быстрее первое. Но наверно оно капец неудобнее

курсор неудобен? да ладно

Ну человеку наверняка надо фронтендик с пажинацией

А курсок надо между запросами из веба хранить гдето

а насколько быстрее?

у меня не тот случай, когда фронтенд с пагинацией, но для этой задачи я бы передал курсор фронтенду при создании

а насколько быстрее?

что быстрее чего ? fetch - итератор

что быстрее чего ? fetch - итератор

выбрать данные из таблицы через create cursor и fetch чем через select ... offset ... limit

если вам нужна выборка с лимитом - используйте limit/offset

а нужен ли вам курсор ?

надо же, столько тонкостей всплывает, я думал это простой вопрос

просто это как "тёплое с мягким"

просто это как "тёплое с мягким"

не очень понял почему теплое с мягким, можете пояснить?

fetch - итератор, limit/offset, внезапно, выборка от и до

ага, последовательность select ... offset ... limit ... можно использовать вместо итератора

вместо нельзя, можно вытащить данные кусками

вот смотрите, вы открыли курсор (он итератор) вы можете совершать с ним операции (ходить туда сюда по нему fetch пока его не закрыли (проще пока не закрыли транзакцию), limit/offset нужен когда вам нужно выбрать определенную пачку данных (самый явный пример постраничник или топ чего-то), т.е. достаточно короткая транзакция весь смысл которой получить n записей

В постгресе курсоры можно юзать после закрытия транзакции если флажок поставить

Ну и это. Лимит оффсет может несогласованные данные выдавать если делаются в разных трансах ибо между трансами данные могут наменять

С другой стороны, незакрытый курсор жрёт ресурсы

И при рестарте субд превращается в тыкву.

А оффсет и лимит работает всегда и не жрёт

Но опять же если это запрос поверх гроуп бая, то он каждый раз (обычно) будет полностью выполнять операцию перед проделыванием лимит ... офсет

А можно подробнее про незакрытый курсор и превращение БД в тыкву? Откуда ноги у этой проблемы растут?

нормальная ли ситуация что запрос повисает навечно при этом жрет проц, если включает в IN подзапрос к несуществующим полям т.е. SELECT "F" FROM "Ta" WHERE "FTest" = true; ERROR: column "FTest" does not exist но этот висит SELECT * FROM "Tb" WHERE "Ftb" IN (SELECT "F" FROM "Ta" WHERE "FTest" = true);

Tb большая?

до 1 млн строк

висело около часа плюнул и прибил

шт тут использовать убийство ))

размер "Tb" всего 198 MB

Join? Или Exists на худой конец

размер "Tb" всего 198 MB

Дело не в размере - а в количестве записей

850000

Знаете как работает ваш второй запрос? Выполняется подзапрос - который возвращает тысяч так 100 записей... и каждая строка в таблице TB проверяется на соотвествие кадой строке в подзапросе - фактически это nested loop без оптимизаций

Знаете как работает ваш второй запрос? Выполняется подзапрос - который возвращает тысяч так 100 записей... и каждая строка в таблице TB проверяется на соотвествие кадой строке в подзапросе - фактически это nested loop без оптимизаций

подзапрос с ошибкой должен падать, в этом же вопрос

вообще с SELECT это пример мне изначально нужен был UPDATE "Tb" при этом SELECT "F" FROM "Ta" WHERE "FTest" = true должен был вернуть около тысячи строк

подзапрос с ошибкой должен падать, в этом же вопрос

Да... не обратил внимание

А какая версия postgres?

нормальная ли ситуация что запрос повисает навечно при этом жрет проц, если включает в IN подзапрос к несуществующим полям т.е. SELECT "F" FROM "Ta" WHERE "FTest" = true; ERROR: column "FTest" does not exist но этот висит SELECT * FROM "Tb" WHERE "Ftb" IN (SELECT "F" FROM "Ta" WHERE "FTest" = true);

ненормально, проверил, у меня падает

в какая у вас версия pg?

Думаю не 9.6 ли с его параллелизмом?

у мну на 9.4 это вылезло

9.4.4 у меня

ii postgresql-9.4 9.4.6-1.pgdg70+1 amd64

попробую ещё на одном инстансе

воспроизводится и на более свежем ii postgresql-9.4 9.4.7-1.pgdg70+1 amd64

запрос до стадии выполнения не должен доходить, на этапе анализа, какого-то там, падает, даже план запроса не строится

у мну и план строится)

я попробовал на 9.5.4 x86 другой платфоре. тож падает

значит у тебя существует колонка

может когда запрос упал на другой бд случайно запустил

нет точно этого поля пробую локально через psql в другую БД не мог никак отправить мож что связаное с типами полей "Tb"."Ftb" и "Ta"."F" оба uuid

больше у меня мыслей пока нет

да, непонятно

во интересноее кино если чуть переписать подзапрос было SELECT * FROM "Tb" WHERE "Ftb" IN (SELECT "F" FROM "Ta" WHERE "FTest" = true); стало SELECT * FROM "Tb" WHERE "Ftb" IN (SELECT "F" FROM "Ta" WHERE "Ta"."FTest" = true); то все нормально ошибку выхлопывает

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

в psql пишешь \с имябд?

ой ступил, не бд же там а таблица сори

к той вот реальные запросы phone=# select * from "HistoryOfServiceTreatments" WHERE "ServiceTreatmentID" IN (SELECT "ServiceTreatmentID" FROM "HistoryOfChat_AppointedSpecs" WHERE "HistoryOfChat_AppointedSpecs"."AnyComments" = 't'); ОШИБКА: колонка HistoryOfChat_AppointedSpecs.AnyComments не существует LINE 1: ...mentID" FROM "HistoryOfChat_AppointedSpecs" WHERE "HistoryOf... ^ phone=# select * from "HistoryOfServiceTreatments" WHERE "ServiceTreatmentID" IN (SELECT "ServiceTreatmentID" FROM "HistoryOfChat_AppointedSpecs" WHERE "AnyComments" = 't'); ^CCancel request sent

второй отменен

значит у тебя поле FTest

есть в таблице основного запроса Tb

есть подозрение в "HistoryOfServiceTreatments" тоже есть поле "AnyComments" собсно в него значения из старой таблицы и надо было перенести но немного с миграции перестарались и удалили "AnyComments" из "HistoryOfChat_AppointedSpecs" ранше

@Cloud66, опередили)

да я проверил, парсинг запроса проходит если поле есть в другой таблице

так это считается ошибкой или я дурак?

вообще конечно косяк постгреса

я думал он ошибку выдавать должен, там вроде строго всегда надо было к колонке псевдоним таблицы указывать.

а оказывается нет

именно из-за подзапроса видимо, если в одном запросе в куче джойнов будут одинаковые колонки то он ошибку выкинет навернго

ладно, спасибо теперь буду старяться не пренебрегать алиасами

вообще конечно косяк постгреса

Мое мнение - это не ошибка

Точно так же поведет себя тот же oracle

Точно так же поведет себя тот же oracle

нет неправда, с патча 11.2.0.2 там ввели ошибку

потому что ранее такое поведение посчитали багом

Щас попробую )) Есть под рукой 11.2.0.4

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

в жойнах точно будет ошибка

Щас сделаю именно как описано

да че там

да в оракле тоже нет ошибки)

https://gyazo.com/0be1ca5414ebb01b430dc67e2420af86

да, я и на 12ом проверил

https://gyazo.com/d6f319f62a02d968b25c965b828a6eff

А долго висит в постгре - как раз из-за NL

ну да, это понятно