Try and maintain ordering of functions #2265
Merged
Conversation
This file contains 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
… into parents when the parent is relying on implicit ordering coming from a function or suitably flagged subquery.
🦋 Changeset detectedLatest commit: 135e8c1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
benjie
commented
Dec 3, 2024
Comment on lines
+2523
to
+2527
| // Don't want to make this a join as it can result in the order being | ||
| // messed up | ||
| if (t2.hasImplicitOrder && !this.joinAsLateral && this.isUnique) { | ||
| continue; | ||
| } |
There was a problem hiding this comment.
22 commits... but this is the bit that matters.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
setoffunction and relational data #2210For a statement like this:
PostgreSQL does not guarantee that the order of rows returned will be the same as the orders defined in the function - this is because you need an explicit
order bystatement in this statement to guarantee order.However, most of the time, the order is maintained due to the way in which PostgreSQL works... But this goes out the window once you add a join - if PostgreSQL decides it's better to evaluate your joined table first and merge with your function call afterwards, then your order can be lost.
This PR attempts to maintain the order of functions more reliably by refusing to inline PgSelect statements into parent queries if the parent query has originated from a set-returning function, and thus has an implicit order.
Originally (see the commit history) I was hoping that we could use
WITH ORDINALITYto solve this, but alas this breaks computed column functions since we can no longer pass the resulting record into the function, since it gains anordinalitycolumn. We could work around that, but it'd make the queries really ugly. Another option would be to move all joins to be subqueries instead, like in V4, but no thanks!In conclusion: you should explicitly order your functions... but if you don't, this should hopefully mean order is generally maintained, maybe, probably, we hope 🤞
Performance impact
Deliberately disables inlining of some queries, resulting in additional roundtrips to the PostgreSQL server.
Security impact
Other than performance, none known.
Checklist
yarn lint:fixpasses.yarn testpasses.RELEASE_NOTES.mdfile (if one exists).