YS
А как указать сортировку снаружи, что первые 5 вывести последние записи, а вторые - уже по кол-ву подписчиков (например)
Хмм... кстати, там же всё равно выбираются все users, зачем вообще UNION (отсортировать как надо да и всё)?
Size: a a a
2021 March 03
DA
Нужно одним запросом вытащить записи юзеров так, чтобы сначала были 5 последних юзеров, а потом все остальные, отсортированные по кол-ву подписчиков \ любому полю, без учета тех 5 юзеров
DA
Первые 5 юзеров должны быть отсортированы по created_at, последующие N - 5 юзеров должны быть отсортированы по полю followers_count например
YS
Нужно одним запросом вытащить записи юзеров так, чтобы сначала были 5 последних юзеров, а потом все остальные, отсортированные по кол-ву подписчиков \ любому полю, без учета тех 5 юзеров
Как они могут быть "без учёта", если они всегда пересекаются?
Это те же записи... а, Вы "забыли" написать, что во втором запросе тоже LIMIT, что ли?
Это те же записи... а, Вы "забыли" написать, что во втором запросе тоже LIMIT, что ли?
DA
Без учета, значит без дублей чтобы было в итоге)
YS
Без учета, значит без дублей чтобы было в итоге)
Нет, я так и не понял задачу.
Либо у Вас нет LIMIT во второй выборке, и они всегда пересекаются (выводятся все пользователи, естественно один раз, просто в таком порядке — это запрос на "хитрую" сортировку, всего лишь).
Либо он есть, и тогда я не понимаю, как конкретно они должны взаимодействовать.
Либо у Вас нет LIMIT во второй выборке, и они всегда пересекаются (выводятся все пользователи, естественно один раз, просто в таком порядке — это запрос на "хитрую" сортировку, всего лишь).
Либо он есть, и тогда я не понимаю, как конкретно они должны взаимодействовать.
DA
Так работает:
Сначала выведет последние 5 записей из users (сортировка по ID) поместит их в first_5_users
А потом выведет всех остальных юзеров и отсортирует их по count_followers
WITH first_5_users AS (Вот этот запрос что делает:
SELECT * FROM users ORDER BY id DESC LIMIT 5
)
SELECT * first_5_users
UNION ALL
SELECT * FROM users WHERE id NOT IN (SELECT id FROM first_5_users) ORDER BY count_followers DESC;
Сначала выведет последние 5 записей из users (сортировка по ID) поместит их в first_5_users
А потом выведет всех остальных юзеров и отсортирует их по count_followers
RL
Так работает:
Сначала выведет последние 5 записей из users (сортировка по ID) поместит их в first_5_users
А потом выведет всех остальных юзеров и отсортирует их по count_followers
WITH first_5_users AS (Вот этот запрос что делает:
SELECT * FROM users ORDER BY id DESC LIMIT 5
)
SELECT * first_5_users
UNION ALL
SELECT * FROM users WHERE id NOT IN (SELECT id FROM first_5_users) ORDER BY count_followers DESC;
Сначала выведет последние 5 записей из users (сортировка по ID) поместит их в first_5_users
А потом выведет всех остальных юзеров и отсортирует их по count_followers
DA
Так работает:
Сначала выведет последние 5 записей из users (сортировка по ID) поместит их в first_5_users
А потом выведет всех остальных юзеров и отсортирует их по count_followers
WITH first_5_users AS (Вот этот запрос что делает:
SELECT * FROM users ORDER BY id DESC LIMIT 5
)
SELECT * first_5_users
UNION ALL
SELECT * FROM users WHERE id NOT IN (SELECT id FROM first_5_users) ORDER BY count_followers DESC;
Сначала выведет последние 5 записей из users (сортировка по ID) поместит их в first_5_users
А потом выведет всех остальных юзеров и отсортирует их по count_followers
А это прям тупость варик, да?
YS
Так работает:
Сначала выведет последние 5 записей из users (сортировка по ID) поместит их в first_5_users
А потом выведет всех остальных юзеров и отсортирует их по count_followers
WITH first_5_users AS (Вот этот запрос что делает:
SELECT * FROM users ORDER BY id DESC LIMIT 5
)
SELECT * first_5_users
UNION ALL
SELECT * FROM users WHERE id NOT IN (SELECT id FROM first_5_users) ORDER BY count_followers DESC;
Сначала выведет последние 5 записей из users (сортировка по ID) поместит их в first_5_users
А потом выведет всех остальных юзеров и отсортирует их по count_followers
Не работает, повторяю. UNION ALL не гарантирует порядка вывода.
Т.е. пока поработает, потом в production когда-то "взорвётся".
И опять-таки, Вы же всех users выводите, зачем эти пляски с UNION-ами?
Т.е. пока поработает, потом в production когда-то "взорвётся".
И опять-таки, Вы же всех users выводите, зачем эти пляски с UNION-ами?
IK
Добрый все вечер. Может кто-то сможет проконсультировать. Проблема следущая была: в базе начали внезапно пачками медленно выполнятся коммиты:
[17324-1] LOG: duration: 50502.100 ms execute S_3: COMMIT. Утилизации по сети, дискам, LA не было никакой. Обычно на этой базе все отрабатывает очень быстро. Курение логов не дело результатов. Рестарт бд помог. Но хотелось бы понять, что это было
DA
Yaroslav Schekin
Не работает, повторяю. UNION ALL не гарантирует порядка вывода.
Т.е. пока поработает, потом в production когда-то "взорвётся".
И опять-таки, Вы же всех users выводите, зачем эти пляски с UNION-ами?
Т.е. пока поработает, потом в production когда-то "взорвётся".
И опять-таки, Вы же всех users выводите, зачем эти пляски с UNION-ами?
Можете подсказать как вывести всех юзеров так, как делает этот запрос?
RL
Можете подсказать как вывести всех юзеров так, как делает этот запрос?
я скинул тебе один вариант, не подходит?
YS
Можете подсказать как вывести всех юзеров так, как делает этот запрос?
Как-то так, по идее:
WITH created_at_ordering AS (
SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC) AS rn
FROM users
)
SELECT *
FROM created_at_ordering
ORDER BY CASE WHEN rn <= 5 THEN rn END, followers DESC
DA
@lrv_october, Yaroslav спасибо большое, буду копать
YS
Добрый все вечер. Может кто-то сможет проконсультировать. Проблема следущая была: в базе начали внезапно пачками медленно выполнятся коммиты:
[17324-1] LOG: duration: 50502.100 ms execute S_3: COMMIT. Утилизации по сети, дискам, LA не было никакой. Обычно на этой базе все отрабатывает очень быстро. Курение логов не дело результатов. Рестарт бд помог. Но хотелось бы понять, что это было
Хмм... для медленного выполнения commit причины могут быть нетривиальные.
Там нет синхронной репликации, prepared transactions и прочего "необычного"?
Если нет — то, казалось бы, запись WAL (почему-то) всё-таки "отстала"... что странно.
А какая полная версия postgres?
И если очень любопытно, можно и дампы WAL посмотреть (pg_waldump), если что.
Там нет синхронной репликации, prepared transactions и прочего "необычного"?
Если нет — то, казалось бы, запись WAL (почему-то) всё-таки "отстала"... что странно.
А какая полная версия postgres?
И если очень любопытно, можно и дампы WAL посмотреть (pg_waldump), если что.
K
Добрый вечер! Подскажите пожалуйста как можно определить количество символов, которые присутствуют в 2х строках. Например
SELECT *
FROM (VALUES('йцукен', 'ьттицролд')) AS foo(a, b)
тут в a и b содержится единственный общий символ "ц"
SELECT *
FROM (VALUES('йцукен', 'ьттицролд')) AS foo(a, b)
тут в a и b содержится единственный общий символ "ц"
VY
Kirill
Добрый вечер! Подскажите пожалуйста как можно определить количество символов, которые присутствуют в 2х строках. Например
SELECT *
FROM (VALUES('йцукен', 'ьттицролд')) AS foo(a, b)
тут в a и b содержится единственный общий символ "ц"
SELECT *
FROM (VALUES('йцукен', 'ьттицролд')) AS foo(a, b)
тут в a и b содержится единственный общий символ "ц"
развернуть строки в массивы символов, найтие пересечение
AL
Добрый все вечер. Может кто-то сможет проконсультировать. Проблема следущая была: в базе начали внезапно пачками медленно выполнятся коммиты:
[17324-1] LOG: duration: 50502.100 ms execute S_3: COMMIT. Утилизации по сети, дискам, LA не было никакой. Обычно на этой базе все отрабатывает очень быстро. Курение логов не дело результатов. Рестарт бд помог. Но хотелось бы понять, что это было
проверяли на предмет аппаратных проблем? dmesg например.
Используете ли синхронную репликацию? Какими средствами проверяли утилизацию (+отзывчивость) дисков?
Используете ли синхронную репликацию? Какими средствами проверяли утилизацию (+отзывчивость) дисков?
K
развернуть строки в массивы символов, найтие пересечение
подскажите а как развернуть строку в массив?