Postgres:använder tidsstämplar för paginering

Låt mig skriva om saker från kommentarer till mitt svar. Du vill använda timestamp typ istället för integer helt enkelt för att det är precis vad den är designad för. Gör manuella konverteringar mellan tidsstämpeltal och timestamp föremål är bara en smärta och du vinner ingenting. Och du kommer att behöva det så småningom för mer komplexa datum- och tidbaserade frågor.

För att svara på en fråga om paginering. Du gör helt enkelt en fråga

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

Om det är den första frågan ställer du in säg lastTimestamp = '3000-01-01' . Annars ställer du in lastTimestamp = last_query.last_row.created .

Optimering

Observera att om tabellen är stor så ORDER BY created DESC kanske inte är effektiv (särskilt om den kallas parallellt med olika intervall). I det här fallet kan du använda flyttande "tidsfönster", till exempel:

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

1 day intervall väljs godtyckligt (justera det efter dina behov). Du kan också sortera resultat i appen.

Om resultaten inte är tomma uppdaterar du (i din app)

lastTimestamp = last_query.last_row.created

(förutsatt att du har sorterat, annars tar du min(last_query.row.created) )

Om resultaten är tomma upprepar du frågan med lastTimestamp = lastTimestamp - interval '1 day' tills du hämtar något. Du måste också stoppa om lastTimestamp blir för låg, d.v.s. när den är lägre än någon annan tidsstämpel i tabellen (som måste hämtas i förväg).

Allt detta är under vissa antaganden för inlägg:

1. new_row.created >= any_row.created och
2. new_row.created ~ current_time
3. Distributionen av new_row.created är mer eller mindre enhetlig

Antagande 1 säkerställer att paginering resulterar i konsekventa data medan antagande 2 endast behövs för standard 3000-01-01 datum. Antagande 3 är att se till att du inte har stora tomma luckor när du måste skicka många tomma frågor.