am
йопта
А если записей дохералион :?
А если записей дохералион :?
Да LIMIT 1 везде же.
йопта
А если записей дохералион :?
Size: a a a
2021 January 19
YS
Ну так индекс-то подходящий есть, я надеюсь? ;)
🌌[
Да LIMIT 1 везде же.
Который отрабатывает после ордера
VF
Мне кажется, что вот этого достаточно будет (добавить
ALL и LIMIT 1 в конце):(
SELECT "file_last_modified_at"
FROM "hars"
WHERE "status" IN ('parsing_queued', 'parsing_in_progress')
ORDER BY "file_last_modified_at" ASC
LIMIT 1
) UNION ALL (
SELECT "file_last_modified_at"
FROM "hars"
WHERE "status" IN ('parsing_succeeded', 'parsing_failed', 'undefined')
ORDER BY "file_last_modified_at" DESC
LIMIT 1
) LIMIT 1
VF
Который отрабатывает после ордера
На ордер есть индекс, конечно
🌌[
Мне кажется, что вот этого достаточно будет (добавить
ALL и LIMIT 1 в конце):(
SELECT "file_last_modified_at"
FROM "hars"
WHERE "status" IN ('parsing_queued', 'parsing_in_progress')
ORDER BY "file_last_modified_at" ASC
LIMIT 1
) UNION ALL (
SELECT "file_last_modified_at"
FROM "hars"
WHERE "status" IN ('parsing_succeeded', 'parsing_failed', 'undefined')
ORDER BY "file_last_modified_at" DESC
LIMIT 1
) LIMIT 1
Ага, и в любом случае будет запись из первой таблички.
Если есть по условиям хоть одна запись
Если есть по условиям хоть одна запись
VF
Ага, и в любом случае будет запись из первой таблички.
Если есть по условиям хоть одна запись
Если есть по условиям хоть одна запись
Отлично, ведь у неё бОльший приоритет
YS
Мне кажется, что вот этого достаточно будет (добавить
ALL и LIMIT 1 в конце):(
SELECT "file_last_modified_at"
FROM "hars"
WHERE "status" IN ('parsing_queued', 'parsing_in_progress')
ORDER BY "file_last_modified_at" ASC
LIMIT 1
) UNION ALL (
SELECT "file_last_modified_at"
FROM "hars"
WHERE "status" IN ('parsing_succeeded', 'parsing_failed', 'undefined')
ORDER BY "file_last_modified_at" DESC
LIMIT 1
) LIMIT 1
Ну так это, как раз, порядка не гарантирует (уже писал). Почему PostgreSQL обязан выполнять первый в тексте вложенный запрос первым, а не наоборот?
🌌[
Отлично, ведь у неё бОльший приоритет
Оно так и всегда будет, запрос то первый.
VF
🌌[
Yaroslav Schekin
Ну так это, как раз, порядка не гарантирует (уже писал). Почему PostgreSQL обязан выполнять первый в тексте вложенный запрос первым, а не наоборот?
Проходит сверху вниз.
Он сделал первый селект, увидел union
сделал второй селект
Он сделал первый селект, увидел union
сделал второй селект
YS
Ага, и в любом случае будет запись из первой таблички.
Если есть по условиям хоть одна запись
Если есть по условиям хоть одна запись
Логически — нет. Планировщику почему-то "захочется" иначе — и будет наоборот.
Я не вижу, почему нет.
Я не вижу, почему нет.
YS
Проходит сверху вниз.
Он сделал первый селект, увидел union
сделал второй селект
Он сделал первый селект, увидел union
сделал второй селект
Планировщик работает совсем не так, вообще-то. ;)
🌌[
Он разбивает на селекты, и уже внутри селектов выставляет приоритеты: есть ли ордер и так далее
🌌[
Селект сам по себе последний
VF
Well. Допустим, мы не уверены в порядке. Можно тогда ORDER BY запихнуть по статусу, как привели в пример выше
A
Добрый день! практически все активные сессии висят с LWLock: SubtransControlLock . Подскажите как искать причину?
YS
Селект сам по себе последний
Ну и что? Запрос-то недетерминированный, PostgreSQL имеет право возвращать любой из результатов, если это планировщику "покажется" выгоднее... да и даже вообще без причин. ;)
VF
Well. Допустим, мы не уверены в порядке. Можно тогда ORDER BY запихнуть по статусу, как привели в пример выше
(SELECT ...) UNION ALL (SELECT ...) ORDER BY (status IN (...)) LIMIT 1🌌[
Yaroslav Schekin
Ну и что? Запрос-то недетерминированный, PostgreSQL имеет право возвращать любой из результатов, если это планировщику "покажется" выгоднее... да и даже вообще без причин. ;)
Хз, мне на работе объясняли что когда юнион, то он берёт первый, а затем второй.