• solrize@lemmy.world
    link
    fedilink
    arrow-up
    15
    arrow-down
    3
    ·
    2 months ago

    Fairly lame article but yeah this is something lemmy used to get wrong. I haven’t paid attention to whether it still does.

    • Jade@programming.devOP
      link
      fedilink
      arrow-up
      13
      arrow-down
      1
      ·
      2 months ago

      They fixed this in version 0.19 pr #3872 (note that the cursor here is a way of hiding a post ID to continue from, as far as I can see).

      Also, lame article? 😖

      • Rimu@piefed.social
        link
        fedilink
        arrow-up
        14
        ·
        2 months ago

        Not lame, I appreciated it and as a result will be implementing ID-based pagination, sometime.

      • Max-P@lemmy.max-p.me
        link
        fedilink
        arrow-up
        8
        arrow-down
        1
        ·
        2 months ago

        Also, lame article? 😖

        It’s pretty short, it could be improved with benchmarks or at least some examples of how that would be implemented efficiently. Maybe a bit of pros and cons, cursor pagination for example doesn’t handle “go directly to page 200” very well. I’ve also seen some interesting hacks to make offset pagination surprisingly fast with a clever subquery.

        I wouldn’t call it lame though.

        • Ephera@lemmy.ml
          link
          fedilink
          arrow-up
          15
          ·
          2 months ago

          I mean, for what it’s worth, you calling it “pretty short” is what made me go read the article, because quite frankly, my attention span isn’t long enough to read through an average-length article for a topic like this.

      • solrize@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        2 months ago

        Ah, thanks for linking that PR. The point made in the article is a good and helpful one, as can be seen by the way so many sites get it wrong, including Lemmy in the past. It’s just that it is pretty thin to make a whole article around. It would be a good thing to bring up in an optimization guide that covers more topics.

        I would be interested to know if there is substantial cost to keeping cursors open for long periods, while the db is being updated. I think given those labels, it may be preferable to do a new select each time the user requests the next page. But I haven’t benchmarked that.

        If you look at how Wikipedia pages through article histories, the labels are timestamps with 1 second resolution.

        Here is another article about the same topic, part of the author’s book on SQL performance:

        https://use-the-index-luke.com/sql/partial-results/fetch-next-page