Please log in. To create a new account, enter the name and password you want to use.
If you supplied an email address when you signed up or added a email later, you can have your password reset.
This user name doesn't exist. If you want to create a new account, just verify your password and log in.
This user name exists. If you want to create a new account, please choose a different name.
Enter the current email address you have registered in your profile. You'll get an email containing your new password.
You have no email address in your profile, so you can't have your password reset.
Password reset. Check your email in a few minutes
That account does not exist.
The email address specified is not registered with this account.
Delivery to this email address has failed.
SELECT * FROM posts ORDER BY id DESC LIMIT 40 OFFSET 40 * 4
which will cause heavy DB load when viewing large page numbers as 40 * (page number) rows needs to be scanned and then skipped by the DB engine, just to return the next 40 posts.
Instead, we could do something like this:
SELECT * FROM posts WHERE id < 886857 ORDER BY id DESC LIMIT 40
where post 886857 is the last post in page 4. This query can be executed very fast on the DB server without much load, because it is very likely the "id" column has a proper index to be utilized by the DB engine. In this case the URL is likely:
The downside is that it is not possible to show a row of page numbers at the bottom of the page to instantly jump to a particular page, since it is hard to know which starting id is for which page. It will instead just have a link of "Previous" and "Next" page.
bao__zhe
https://medium.com/swlh/mongodb-pagination-fast-consistent-ece2a97070f3
Without access to the source code my educated guess is that the current implementation is using SKIP-LIMIT style of pagination by inspecting the URL:
https://yande.re/post?page=5
This roughly corresponds to the below SQL query:
SELECT *
FROM posts
ORDER BY id DESC
LIMIT 40
OFFSET 40 * 4
which will cause heavy DB load when viewing large page numbers as 40 * (page number) rows needs to be scanned and then skipped by the DB engine, just to return the next 40 posts.
Instead, we could do something like this:
SELECT *
FROM posts
WHERE id < 886857
ORDER BY id DESC
LIMIT 40
where post 886857 is the last post in page 4. This query can be executed very fast on the DB server without much load, because it is very likely the "id" column has a proper index to be utilized by the DB engine. In this case the URL is likely:
https://yande.re/post?after=886857
The downside is that it is not possible to show a row of page numbers at the bottom of the page to instantly jump to a particular page, since it is hard to know which starting id is for which page. It will instead just have a link of "Previous" and "Next" page.
@admin6 do you want to give this idea a try?