3 ms·
Well, except that TFA explains what DB cursors are and why they are faster than page offsets (because they skip DB entries).
by G3rn0ti 4y ago
Well, except that TFA explains what DB cursors are and why they are faster than page offsets (because they skip DB entries).
- theogravity 4y agoIt needs to talk about how to actually implement it. Most articles like this one mention its existence and why it's good, but generally stop there.
- G3rn0ti 4y agoPostgres supports cursors and documents them very well: https://www.postgresql.org/docs/current/plpgsql-cursors.html https://www.postgresql.org/docs/current/plpgsql-cursors.html Basically, you declare a cursor like that: DECLARE cname CURSOR FOR <select statement>; You can pass the cursor’s name „cname“ (and even store it on the client side, although, best encrypted) and obtain the „next“ slice of your data corresponding to the query on demand like that: FETCH next cname; Not sure you really gain that much performance on everyday queries but with a large number of rows it might.
- chowells 4y agoOf course, this isn't what the article is talking about...
- theteapot 4y agoTFA isn't talking about that kind of cursor.
- jsmith99 4y agoI'm pretty sure they aren't using actual SQL cursors as that wouldn't scale well so it's probably not a 'DB cursor'. It's a shame as actual cursors are the native database way to do pagination.
- thaumasiotes 4y ago> TFA explains what DB cursors are and why they are faster than page offsets (because they skip DB entries) Except that no such information appears in the article. Here's the entirety of the explanation: >> Once you’ve been returned a cursor, you can provide it in your requests to act as a farther-along starting point within your data entries. The server is then able to efficiently skip all entries that come before your specified cursor value