Size: a a a

pgsql – PostgreSQL

2021 March 10

YS

Yaroslav Schekin in pgsql – PostgreSQL
Jakh☭ngir Karimov
оригинальный запрос был такой:
  SELECT t.gd_tin as tin, 
        count(*) OVER (PARTITION BY t.gd_tin) as as_director_count,
        t.name
 FROM np1_leg t
      where t.gd_tin is not null and t.gd_tin > 1 and t.state < 30    
      order by as_director_count desc

но есть ли способ с having'ом в такой ситуации, так как select * from (some query) запрашивает еще один select запрос, который по-моему является еще одной нагрузкой?
Нет, способа с HAVING нет, потому что в запросе нет группировки; и всё равно вычисления в SELECT list (в т.ч. window functions) выполняются после HAVING.
источник

В

Влад in pgsql – PostgreSQL
Коллеги, подскажите плиз. Есть блок try catch. Внутри есть saveAndFlush. Будет ли записана в бд сущность если изза какогото кода после saveAndFlush выпадет исключение
источник

D

Dmitriy in pgsql – PostgreSQL
Влад
Коллеги, подскажите плиз. Есть блок try catch. Внутри есть saveAndFlush. Будет ли записана в бд сущность если изза какогото кода после saveAndFlush выпадет исключение
В PostgreSQL нет метода saveAndFlush
источник

В

Влад in pgsql – PostgreSQL
Dmitriy
В PostgreSQL нет метода saveAndFlush
да, это из JPA Spring java. Однако это сохранение в postgresql бд
источник

D

Dmitriy in pgsql – PostgreSQL
Влад
да, это из JPA Spring java. Однако это сохранение в postgresql бд
И что? Какой/какие там запросы идут в БД, в транзакции или нет и т.п.?
источник

В

Влад in pgsql – PostgreSQL
Dmitriy
И что? Какой/какие там запросы идут в БД, в транзакции или нет и т.п.?
Блок try {есть создание сущности, заполнение ее полей. Далее через saveAndFlush() сохранение этой сущности. Далее после строки сохранения идет логика отправки смс уведомления о сохранении(вот тут, очень большая вероятность упасть) } catch (обработка ошибки) . Вопрос, если в логике отправки выпадет ошибка - сущность уже будет сохранена или нет в бд
источник

D

Dmitriy in pgsql – PostgreSQL
Влад
Блок try {есть создание сущности, заполнение ее полей. Далее через saveAndFlush() сохранение этой сущности. Далее после строки сохранения идет логика отправки смс уведомления о сохранении(вот тут, очень большая вероятность упасть) } catch (обработка ошибки) . Вопрос, если в логике отправки выпадет ошибка - сущность уже будет сохранена или нет в бд
For instance, imagine a scenario where we have to execute a stored procedure that expects a property of the entity, which we're going to save. In this case, the save() method won't work since the changes are not in sync with the DB and the stored procedure doesn't know about the changes. The saveAndFlush() method is perfectly suited for this kind of scenario.
источник

D

Dmitriy in pgsql – PostgreSQL
Unlike save(), the saveAndFlush() method flushes the data immediately during the execution.
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
Коллеги, есть ли какие-либо серьезные причины не делать select field from t1 join t2 on t1.field like t2.mask ? Мне тут понадобилось шерстить таблицы по маскам, заданным пользователями
источник

В

Влад in pgsql – PostgreSQL
Dmitriy
Unlike save(), the saveAndFlush() method flushes the data immediately during the execution.
моя проблема, что если в try все упадет, то нельзя иметь эту сущность в бд. Она должна там быть только если успешно отправиться смс
источник

D

Dmitriy in pgsql – PostgreSQL
Влад
моя проблема, что если в try все упадет, то нельзя иметь эту сущность в бд. Она должна там быть только если успешно отправиться смс
Значит в catch вызывайте метод удаления. Транзакцию тут использовать нельзя, иначе базе будет плохо
источник

В

Влад in pgsql – PostgreSQL
Dmitriy
Значит в catch вызывайте метод удаления. Транзакцию тут использовать нельзя, иначе базе будет плохо
интересное решение) спасибо
источник

D

Dmitriy in pgsql – PostgreSQL
Влад
интересное решение) спасибо
Ну а как? Если в транзакции это будете делать - получите долгие транзакции, которые PosgtreSQL не любит
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Andrey Tatarnikov
Коллеги, есть ли какие-либо серьезные причины не делать select field from t1 join t2 on t1.field like t2.mask ? Мне тут понадобилось шерстить таблицы по маскам, заданным пользователями
По-моему, нет. Производительность будет почти наверняка так себе, но Вы это и так знаете, я думаю.
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
Yaroslav Schekin
По-моему, нет. Производительность будет почти наверняка так себе, но Вы это и так знаете, я думаю.
ну тут, как обычно, главное чтобы никого из соседних клиентов не забгрызгало, а так пусть бы себе шуршало раз в день
альтернатив на sql все равно не особо, или мне фантазии не хватает
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Andrey Tatarnikov
ну тут, как обычно, главное чтобы никого из соседних клиентов не забгрызгало, а так пусть бы себе шуршало раз в день
альтернатив на sql все равно не особо, или мне фантазии не хватает
Хмм... а какие тут альтернативы и не на SQL?
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
ELK, например и ему подобные
источник

D

Dmitriy in pgsql – PostgreSQL
Sphinx/Manticore (но это не точно)
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Andrey Tatarnikov
ELK, например и ему подобные
Ну-ну. А Вам не кажется, что (если база данных у Вас уже в production и т.п.), что это будет гораздо хуже (я о расходах на реализацию и интеграцию, если что)?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Andrey Tatarnikov
ELK, например и ему подобные
И да, даже если бы это было там исходно — там что, "магические" алгоритмы поиска?
Вам же нужны (хоть и ограниченные, но) регулярные выражения, а не FTS.
источник