Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize PgSelect fetches for pure ancilliary information #2327

Open
benjie opened this issue Jan 20, 2025 · 0 comments
Open

Optimize PgSelect fetches for pure ancilliary information #2327

benjie opened this issue Jan 20, 2025 · 0 comments

Comments

@benjie
Copy link
Member

benjie commented Jan 20, 2025

Currently pgSelect yields an array of tuples. But sometimes we need to know extra information from this, such as "does it have more rows available". Currently we do this, disgustingly, by adding a .hasMore property to the array. This is hideous because it means V8 can no longer treat it as a pure array, and also because no-one expects arrays to have extra properties...

Anyway; on top of that, with #2326 we can no longer evaluate first/last/etc up front and so we pass them through to runtime. But because "hasNextPage" is now dependent on the result of the PgSelect (and no longer forks beforehand), the PgSelect has to run and yield an array of results just so that for a query like

messagesConnection {
pageInfo {
hasNextPage
hasPreviousPage
}
}

we can determine there is no previous/next page. The system cannot determine that we only need the "hasMore" property and don't actually need to perform the select, and that we never iterate over the array, so it has to perform the fetch even though it's not used.

I think that we want PgSelect to actually yield an object containing the list of rows and meta information; and if the rows are never requested then no need to fetch them. I.e.:

-const $users = blah.find();
-const $hasMore = access($users, 'hasMore');
+const $usersFetch = blah.find();
+const $users = $usersFetch.rows();
+const $hasMore = $usersFetch.hasMore();

This would be quite a big, breaking change (albeit fairly easy to migrate to), so if we're to do this we should do it before the launch of V5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🌳 Triage
Development

No branches or pull requests

1 participant