If you are wondering why lemmy is moving away from offset pagination since 0.19, here is a nice article about it

  • lysdexic@programming.dev
    link
    fedilink
    English
    arrow-up
    4
    ·
    11 months ago

    For the article-impaired,

    Using OFFSET+LIMIT for pagination forces a full table scan, which in large databases is expensive.

    The alternative proposed is a cursor+based navigation, which is ID+LIMIT and requires ID to be an orderable type with monotonically increasing value.

    • Blackmist@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 months ago

      Which it almost never is.

      Any data as simple as that is unlikely to reach a number of rows likely to cause an issue with performance.

    • lysdexic@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      edit-2
      11 months ago

      Having said this, I’d say that OFFSET+LIMIT should never be used, not because of performance concerns, but because it is fundamentally broken.

      If you have rows being posted frequently into a table and you try to go through them with OFFSET+LIMIT pagination, the output from a pagination will not correspond to the table’s contents. Fo each row that is appended to the table, your next pagination will include a repeated element from the tail of the previous pagination request.

      Things get even messier once you try to page back your history, as now both the tip and the tail of each page will be messed up.

      Cursor+based navigation ensures these conflicts do not happen, and also has the nice trait of being easily cacheable.