Postgres:използване на времеви клейма за страниране

Нека пренапиша нещата от коментарите към моя отговор. Искате да използвате timestamp тип вместо integer просто защото точно за това е проектиран. Извършване на ръчни преобразувания между цели числа с клеймо за време и timestamp обекти е просто болка и не печелите нищо. И в крайна сметка ще ви трябва за по-сложни заявки, базирани на дата и час.

За да отговоря на въпрос относно пагинацията. Просто правите заявка

SELECT *
FROM table_name
WHERE created < lastTimestamp
ORDER BY created DESC
LIMIT 30

Ако това е първата заявка, тогава задавате да речем lastTimestamp = '3000-01-01' . В противен случай задавате lastTimestamp = last_query.last_row.created .

Оптимизация

Имайте предвид, че ако таблицата е голяма, тогава ORDER BY created DESC може да не е ефективно (особено ако се извиква паралелно с различни диапазони). В този случай можете да използвате движещи се „времеви прозорци“, например:

SELECT *
FROM table_name
WHERE
    created < lastTimestamp
    AND created >= lastTimestamp - interval '1 day'

1 day интервалът се избира произволно (настройте го според вашите нужди). Можете също да сортирате резултатите в приложението.

Ако резултатите не са празни, актуализирате (в приложението си)

lastTimestamp = last_query.last_row.created

(ако приемем, че сте извършили сортирането, в противен случай ще вземете min(last_query.row.created) )

Ако резултатите са празни, повтаряте заявката с lastTimestamp = lastTimestamp - interval '1 day' докато не вземете нещо. Също така трябва да спрете, ако lastTimestamp стане твърде нисък, т.е. когато е по-нисък от всяко друго времево клеймо в таблицата (което трябва да бъде предварително извлечено).

Всичко това е при някои предположения за вмъквания:

1. new_row.created >= any_row.created и
2. new_row.created ~ current_time
3. Разпространението на new_row.created е повече или по-малко еднакво

Предположение 1 гарантира, че пагинирането води до последователни данни, докато предположение 2 е необходимо само за 3000-01-01 по подразбиране дата. Предположение 3 е да се уверите, че нямате големи празни пропуски, когато трябва да подадете много празни заявки.