You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed a bug when using the filtered random button where the selected posts would always be in the first few hundreds, seemingly not selecting the later ones at all.
After investigating the issue, it looks like the current method for selecting posts only does so on the cached pages (pageSize * cachePages first posts), which seems like undesired behavior. This fixes it by choosing an offset from the total number of posts.
From the few tests I've done it works as expected.
While I was in this file, I noticed a minor bug with the query: using OFFSET + LIMIT without an ORDER_BY can lead to underfined behavior (https://www.postgresql.org/docs/current/queries-order.html#QUERIES-ORDER).
I'm not 100% sure this can cause a bug in practice, but might as well follow the manual.
https://www.postgresql.org/docs/current/queries-limit.html
When using LIMIT, it is important to use an ORDER BY clause that constrains the result rows into a unique order. Otherwise you will get an unpredictable subset of the query's rows. You might be asking for the tenth through twentieth rows, but tenth through twentieth in what ordering? The ordering is unknown, unless you specified ORDER BY.
From what I'm reading, there is no undefined behavior here. The order is just unspecified and unpredictable, and that's fine since we only do this to choose one record at random, we do not care about relative order of records and sample uniformly anyway.
I have suspicion that specifying order might introduce some performance overhead. Or maybe it might it faster, idk. Either way I wouldn't change this part unless there is a supporting benchmark(for large databases) or an actual bug to be fixed here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I noticed a bug when using the filtered random button where the selected posts would always be in the first few hundreds, seemingly not selecting the later ones at all.
After investigating the issue, it looks like the current method for selecting posts only does so on the cached pages (
pageSize * cachePagesfirst posts), which seems like undesired behavior. This fixes it by choosing an offset from the total number of posts.From the few tests I've done it works as expected.
While I was in this file, I noticed a minor bug with the query: using OFFSET + LIMIT without an ORDER_BY can lead to underfined behavior (https://www.postgresql.org/docs/current/queries-order.html#QUERIES-ORDER).
I'm not 100% sure this can cause a bug in practice, but might as well follow the manual.