Всем привет! Подскажите пожалуйста. Как могу добавить в конец при

выборке даты которые после сегодняшнего дня? Вот к примеру как с nulls last, только с будущими датами.

Результат должен быть таким записи до сегодняшней даты, а после должны быть записи после сегодняшней даты

"Результат должен быть таким записи до сегодняшней даты, а после должны быть записи после сегодняшней даты" -> не поверите, но если отсортируете order by date asc, будет именно то, что вам нужно:)

Так и делаю, но результат не тот)

Он идет с будущей датой, потом приходит к сегодняшней дате, после выбирает старые даты. А мне надо начинать с сегодняшней даты, после старые даты, а после будущие даты

скиньте пример=) Как он может быть не тот, я не знаю) в этом суть сортировки как раз, чтобы упорядочить данные

Order by case

Спасибо большое, попробую)

ну сделайте через union тогда. 3 селекта. 1 выберет сегодняшние даты + поле для order, какой-нибудь 1 as order_number 2 селект выберет даты меньше сегодняшней + поле 2 as order_number 3 выберет даты больше сегодняшней + поле 3 as order_number и затем order by order_number

представляю скорость этого решения

оверхед не сильный будет. Индекс тот же, прогруженный в shared_buffers, + worker'ы могут параллельно выполнить запрос. Зато будет более понятный запрос

3 прохода вместо одного...

и что? сложность одна. По сути, только на итерацию. Вы серьёзно думаете, что для btree это будет проблема?

зачем? когда можно использовать обычный case

три частичных прохода. или у вас индексов нет совсем?

А тут надо понять, что вообще нужно. Я подозреваю, это какая-то интерфейсная идея с упорядочиванием условных тикетов для исполнителей. Если так, то решение надо делать с учётом пейджинации, используемого ORM и пр

если есть индекс - то писать кривой метод с 3 проходами?

Да что хотите пишыте. Просто если там есть проход по индэксу вместо сортировки в памяти -- то это вероятно будет на копейку быстрее, чем выдумывать варжэние сортировки -- которое простое, но скорее всего заставить постгрес его выводить из индэкса не получится.

order by CASE WHEN (started_at::date >= CURRENT_DATE) THEN 0 ELSE 1 END desc nulls last Вроде так получилось, но он почему-то nulls не добавляет в конец и реузльтат какой-то смешанный

я не согласен, что подход кривой с 3 проходами. Сложность алгоритма в целом не меняется. а из плюсов: 1) можно построить 3 индекса вместо 1. Если рассматривать пограничный кейс на больших данных, вам не хватит ОЗУ прогрузить полностью индекс, а в моём решении можно будет прогрузить 3 маленьких индекса, если не разом, то по отдельности. 2) касательно понимания запроса - это лучше, т.к логически выделены участки, которые дают определённую выборку. И если бы сохранялся ордеринг при union, что в принципе, в будущем может и будет сделано (почему бы и нет? например какой-нибудь ordered union?:) ), то можно вообще будет затем данные не сортировать.

Это пишэтся как ORDER BY started_at::date < CURRENT_DATE nulls last заодно и нуллы поправятся. (Правда, тут наоборот сначала будущие даты -- но так и в вашэм выражэнии).

Вон то выражэние, которое вы указали так пишэтся, а не вся сортировка.

что там выдумывать? 20 символов. вариант с union как раз выдумка и выглядит как монстр и работает медленнее и главное подход к решению неверный. а потом где-то не будет индекса...

аргументируйте, почему подход медленнее работает? вы же понимаете, что 3 * N/3 даёт N?:) как и в случае с полным, пусть даже Index only scan, будет N Вы серьёзно думаете, что итератор, который ничего не делает, даёт существенные накладные расходы?) у вас есть пирог. вы поделили его на 3 части и начали есть. вы утверждаете, что если бы вы его на 3 части не поделили, вы слопали бы его быстрее:)

это же сортировка, а не выборка. по фильтру выберется условно 100 строк и дальше сортировка