<p></p>
<p dir="auto">You bring up a valid point about the limitations of cursor-based pagination with sorting. Cursor pagination works efficiently when sorting by a unique or sequential field (like <code class="notranslate">id</code>, <code class="notranslate">created_at</code>, or <code class="notranslate">updated_at</code>), but it breaks down when we try to sort by non-unique columns (e.g., <code class="notranslate">name</code>, <code class="notranslate">status</code>).</p>
<p dir="auto">To address this, there are a couple of potential solutions:</p>
<ol dir="auto">
<li>
<p dir="auto"><strong>Combined Sorting</strong>: We could continue using cursor-based pagination but with a fallback to a secondary unique column like <code class="notranslate">id</code>. This way, sorting by <code class="notranslate">name</code> or <code class="notranslate">status</code> would still function but would maintain stable pagination by also ordering by <code class="notranslate">id</code> to ensure uniqueness:</p>
<div class="highlight highlight-source-sql" dir="auto"><pre class="notranslate"><span class="pl-k">ORDER BY</span> name <span class="pl-k">ASC</span>, id <span class="pl-k">ASC</span></pre></div>
<p dir="auto">This approach would retain the benefits of cursor-based pagination while allowing some flexibility with sorting.</p>
</li>
<li>
<p dir="auto"><strong>Offset-based Pagination</strong>: If we want to fully support sorting by arbitrary columns, we could switch to offset-based pagination when sorting by non-unique columns. This is less efficient on larger datasets but avoids the problem of ambiguous cursor positions.</p>
</li>
<li>
<p dir="auto"><strong>Hybrid Approach</strong>: Implement cursor-based pagination for sortable fields that are unique (like <code class="notranslate">id</code> or timestamps), and fallback to offset-based pagination for others.</p>
</li>
</ol>
<p dir="auto">Before proceeding, I’d like to get some thoughts on which approach fits best with our performance requirements and use cases. If we'd prefer sticking with cursor-based pagination, I can explore implementing the combined sorting method, as it strikes a balance between efficiency and flexibility.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/issues/5259#issuecomment-2411376926">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLMUWXE4K3FVAD3QRGTZ3PF2XAVCNFSM6AAAAABP3P6O2WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJRGM3TMOJSGY">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAK2OLNQ6OUJ5NGC2LQM3BLZ3PF2XA5CNFSM6AAAAABP3P6O2WWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUPXKYR4.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openstreetmap/openstreetmap-website/issues/5259/2411376926</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/issues/5259#issuecomment-2411376926",
"url": "https://github.com/openstreetmap/openstreetmap-website/issues/5259#issuecomment-2411376926",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>