Sorted indexes and pagination: DESC vs DESC NULLS LAST #1040
Labels
No labels
approved, awaiting change
broken setup
bug
cannot reproduce
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs change/feedback
needs docs
needs tests
not a bug
not our bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
AkkomaGang/akkoma#1040
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Our SQL pagination helper
lib/pleroma/paginationalways sorts byDESC NULLS LASTorASC NULLS LAST. However it typically acts on primary keys or other non-nullable columns. If now an index was created with justDESCorASCpostgres won’t use the index at all or use it, but still load all entries, resort them and only then limit.In particular this affects
"context"queries. Inlib/pleroma/web/activity_pub.exitself there are multiple functions querying all or just the mo st recent post of a context by ordering by the activityidusing a plainDESC. However, when we query theNmost recent posts for conversation timelines (up until now) another "DESC NULLS LAST" order statement got applied.Given we, to my knowledge, never use this on nullable fields, we might as well drop the
NULLS LAST. However, we’ll need to recheck all related indexes and make sure they are also changed if necessary.