Closed adamni21 closed 4 months ago
Latest commit: 4e102b1a1cd232e6f6703df0706415f01831dab2
The changes in this PR will be included in the next version bump.
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
Excellent work; thanks for this! I've optimized it a bit, handled more edge cases, and added another test to check handling of partial variables (and undefined variables). I've also fixed some existing bugs I noticed at the same time which somehow have flown under the radar until now.
Lovely. Happy to help 😀
Description
This PR aims to improve the performance for large input arg types. Eg. a filter input with many elements in the and/or field.
Discussed in discord: https://discord.com/channels/489127045289476126/498852330754801666/1261317211604123718
Only serves as an interim solution, while
eval*
is being removed/the filter plugin gets rewritten to be evaluated at execution time instead of planning time.Performance impact
Vast improvement for the mentioned use case, >500x for a filter with 20 "or filters" on a filter type with ~250 fields. Maybe a slight performance decrease, for general usage, due to increased operation plan splitting.
Security impact
Unknown (likely none)
Checklist
yarn lint:fix
passes.yarn test
passes.RELEASE_NOTES.md
file (if one exists).I didn't add tests, but it should already be covered by
grafast/dataplan-pg/__tests__/queries/conditions/complex-filter.test.graphql
Edit: Added an almost equivalent of the above test, which specifies the filters via variables, instead of inlining it into the query.