Oui mais au bout d’un moment, plutôt que de faire de la bidouille t’achète une autre grappe, et tu montes un cluster ad hoc hein 
Sauf quand t’es pauvre :ane:
Remarque:
L’index ne fait pas gagner du temps parce qu’il est plus petit, mais parce qu’il indexe les données par un seul tri, ce qui permet un accès par valeur à une donnée par un algo de dichotomie en o(ln(n) ) là ou il faut o(n) pour un algo basique de parcours systématique de la table.
Ceci dit, je suis surpris que LIMIT n’exploite pas ces index (faiblesse de le BD?), mais je ne m’en sers pas pour mes applis vu qu’on met systématiquement tout en RAM pour faire la pagination côté serveur d’appli.
mon avis:
J’aurais tendance à préférer les méthodes SQL ANSI dans la mesure ou elles sont plus portable, mais si tu es sur de n’avoir jamais à porter l’application, pourquoi pas, l’important étant de bien isoler ces “bidouillesoptimisations” pour revenir facilement en arrière au besoin. le between m’avais l’air d’être un bon compromis, avec l’inconvénient de supposer qu’il n’y a aucun trou dans la numérotation des id. (ce qui sera faux si tu fait du ménage dans ton livre d’or)
si tu nous tend le bâton en permanence aussi 
'foiré !
une autre solution serait d’utiliser la technique des curseurs.
http://www.postgresql.org/docs/8.2/static/…ql-cursors.html