Lasciami riscrivere le cose dai commenti alla mia risposta. Vuoi usare timestamp digita invece di integer semplicemente perché è esattamente ciò per cui è stato progettato. Eseguire conversioni manuali tra numeri interi timestamp e timestamp oggetti è solo un dolore e non guadagni nulla. E alla fine ne avrai bisogno per query più complesse basate su datetime.
Per rispondere a una domanda sull'impaginazione. Fai semplicemente una query
SELECT *
FROM table_name
WHERE created < lastTimestamp
ORDER BY created DESC
LIMIT 30
Se è la prima query, imposti dire lastTimestamp = '3000-01-01' . Altrimenti imposti lastTimestamp = last_query.last_row.created .
Ottimizzazione
Nota che se la tabella è grande allora ORDER BY created DESC potrebbe non essere efficiente (soprattutto se chiamato in parallelo con intervalli diversi). In questo caso puoi utilizzare le "finestre temporali" mobili, ad esempio:
SELECT *
FROM table_name
WHERE
created < lastTimestamp
AND created >= lastTimestamp - interval '1 day'
Il 1 day l'intervallo viene selezionato arbitrariamente (regolarlo in base alle proprie esigenze). Puoi anche ordinare i risultati nell'app.
Se i risultati non sono vuoti, aggiorni (nella tua app)
lastTimestamp = last_query.last_row.created
(supponendo che tu abbia eseguito l'ordinamento, altrimenti prendi min(last_query.row.created) )
Se i risultati sono vuoti, ripeti la query con lastTimestamp = lastTimestamp - interval '1 day' finché non prendi qualcosa. Inoltre devi interrompere se lastTimestamp diventa basso, cioè quando è inferiore a qualsiasi altro timestamp nella tabella (che deve essere precaricato).
Tutto ciò è sotto alcune ipotesi per gli inserti:
new_row.created >= any_row.createdenew_row.created ~ current_time- La distribuzione di
new_row.createdè più o meno uniforme
Il presupposto 1 garantisce che l'impaginazione produca dati coerenti mentre il presupposto 2 è necessario solo per il 3000-01-01 predefinito Data. Il presupposto 3 è assicurarsi di non avere grandi spazi vuoti quando devi emettere molte query vuote.
