🌌[
(SELECT ...) UNION ALL (SELECT ...) ORDER BY (status IN (...)) LIMIT 1Можно
Size: a a a
2021 January 19
am
Там вроде бы ситуация «никто не обещал, но будет всегда».
UNION более страшный, он DISTINCT делает.
UNION более страшный, он DISTINCT делает.
Короче. делайте что хотите, но не говорите потом, что вас не предупреждали.
YS
(SELECT ...) UNION ALL (SELECT ...) ORDER BY (status IN (...)) LIMIT 1А, ну да (мне показалось, что статусы во вложенных запросах одинаковые, извините — да я и в своём примере так написал).
Т.е. в Вашем варианте нужна сортировка по статусам.
Т.е. в Вашем варианте нужна сортировка по статусам.
am
Хз, мне на работе объясняли что когда юнион, то он берёт первый, а затем второй.
Мне на работе пару раз встречались коллеги, которые «зачем ты пишешь ORDER BY id, оно же автоматически».
am
Вот как вы им объясните, почему «автоматически» однажды (после первого пылесосинга) не сработает?
YS
Хз, мне на работе объясняли что когда юнион, то он берёт первый, а затем второй.
Можете теперь объяснить им, что они были неправы. ;)
Простое же общее правило — без ORDER BY во внешнем запросе порядок не гарантируется.
ORDER BY во вложенных запросах могут просто игнорироваться, если не меняют их результат ни в чём, кроме сортировки (но PostgreSQL этого не делает, насколько я помню), кстати.
Простое же общее правило — без ORDER BY во внешнем запросе порядок не гарантируется.
ORDER BY во вложенных запросах могут просто игнорироваться, если не меняют их результат ни в чём, кроме сортировки (но PostgreSQL этого не делает, насколько я помню), кстати.
VF
Спасибо большое ещё раз за подобные полезные дикуссии 😊
R
Yaroslav Schekin
Можете теперь объяснить им, что они были неправы. ;)
Простое же общее правило — без ORDER BY во внешнем запросе порядок не гарантируется.
ORDER BY во вложенных запросах могут просто игнорироваться, если не меняют их результат ни в чём, кроме сортировки (но PostgreSQL этого не делает, насколько я помню), кстати.
Простое же общее правило — без ORDER BY во внешнем запросе порядок не гарантируется.
ORDER BY во вложенных запросах могут просто игнорироваться, если не меняют их результат ни в чём, кроме сортировки (но PostgreSQL этого не делает, насколько я помню), кстати.
Помнится, была статья на хабре от тензора (вроде), в которой предлагалось оптимизация с использованием того факта, что сначала выполняется первый запрос (и второй может не выполниться, если limit превышен).
https://habr.com/ru/company/tensor/blog/479508/ (часть про BitmapOr vs UNION)
https://habr.com/ru/company/tensor/blog/479508/ (часть про BitmapOr vs UNION)
IC
Коллеги, а почему запросы могут не попадать в pg_stat_statements?
Запросы от BI-системы вида:
BEGIN;declare "SQL_CUR0x7f8b400c88af" cursor with hold for SELECT * FROM Tbl;fetch 2048 in "SQL_CUR0x7f8b400c88af"
Это из-за курсора? Можно ли что-то с этим сделать?
Запросы от BI-системы вида:
BEGIN;declare "SQL_CUR0x7f8b400c88af" cursor with hold for SELECT * FROM Tbl;fetch 2048 in "SQL_CUR0x7f8b400c88af"
Это из-за курсора? Можно ли что-то с этим сделать?
VY
Коллеги, а почему запросы могут не попадать в pg_stat_statements?
Запросы от BI-системы вида:
BEGIN;declare "SQL_CUR0x7f8b400c88af" cursor with hold for SELECT * FROM Tbl;fetch 2048 in "SQL_CUR0x7f8b400c88af"
Это из-за курсора? Можно ли что-то с этим сделать?
Запросы от BI-системы вида:
BEGIN;declare "SQL_CUR0x7f8b400c88af" cursor with hold for SELECT * FROM Tbl;fetch 2048 in "SQL_CUR0x7f8b400c88af"
Это из-за курсора? Можно ли что-то с этим сделать?
а как ищите?
IC
select * from pg_stat_statements where query like '%SQL%'
IC
Да и глазами поискал, система чистая, запросов мало. Попадают только системные или из бобра.
YS
Помнится, была статья на хабре от тензора (вроде), в которой предлагалось оптимизация с использованием того факта, что сначала выполняется первый запрос (и второй может не выполниться, если limit превышен).
https://habr.com/ru/company/tensor/blog/479508/ (часть про BitmapOr vs UNION)
https://habr.com/ru/company/tensor/blog/479508/ (часть про BitmapOr vs UNION)
Если от этого зависит корректность результата — то это зря (в очередном minor это всё запросто изменится... и претензии тех, кто не знает основ SQL, вряд ли кто-то примет во внимание ;) ).
Но в статье это, с виду, просто для оптимизации сделано — т.е. ничего страшного, если в планировщике что-то поменяют, не случится.
Но вот это:
слишком сильно сказано — не "гарантирует", а пока так работает (и не факт, что всегда).
Но в статье это, с виду, просто для оптимизации сделано — т.е. ничего страшного, если в планировщике что-то поменяют, не случится.
Но вот это:
«Внешний» LIMIT 1 гарантирует, что поиск завершится при нахождении первой же записи. И если она найдется уже в первом блоке, выполнение второго осуществляться не будет (never executed в плане).
слишком сильно сказано — не "гарантирует", а пока так работает (и не факт, что всегда).
am
Черт! Придется дополнительно отсортировать результат из двух строк.
am
Почему мир так несовершенен? Как у вас только нервы выдерживают эту работу?
MZ
Почему мир так несовершенен? Как у вас только нервы выдерживают эту работу?
Оставь надежду всяк сюда входящий.
VY
select * from pg_stat_statements where query like '%SQL%'
а транзакции с этим курсором уже завершились?
а если искать по
а если искать по
~ 'declare' — что-то есть?IC
а транзакции с этим курсором уже завершились?
а если искать по
а если искать по
~ 'declare' — что-то есть?Да. завершились. По 'declare' ничего нет.
IC
Один раз удалось поймать, что BI перед закрытием сессии посылает DISCARD ALL, это может влиять?
VY
Один раз удалось поймать, что BI перед закрытием сессии посылает DISCARD ALL, это может влиять?
да не должно, это параметры сессии сбрасываются. а
пробовали искать case-insensitive?
pg_stat_statements.max сколько у вас?пробовали искать case-insensitive?