[mike_hock]

TL;DR: The headline. TFA doesn't really add any information.

[G3rn0ti]

Well, except that TFA explains what DB cursors are and why they are faster than page offsets (because they skip DB entries).

[jsmith99]

I'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]

> 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

[theteapot]

TFA isn't talking about that kind of cursor.

[theogravity]

It 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]

Postgres supports cursors and documents them very well:

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]

Of course, this isn't what the article is talking about...