That’s not how pre_get_posts works, or what it’s for.
The pre_get_posts filter, is an opportunity to change set or modify the arguments of a WP_Query object before it fetches posts from the information.
For example, here is one that modifies the homepage query to only fetch 5 posts:
function tomjn_fetch_five_posts( \WP_Query $q ) {
if ( $q->is_main_query() && $q->is_home() ) {
$q->set( 'posts_per_page', 5 );
}
}
add_action( 'pre_get_posts', 'tomjn_fetch_five_posts' );
In your case, it’s not clear what you’re trying to do, but lets say we only want to show the post with the highest session meta key value, we might do:
$q->set( 'meta_key', 'session');
$q->set( 'meta_value', $lastSessionNumber );
However, both this, and the SQL query you wrote have major performance and traffic scaling problems, the kind that can’t be swept under the rug or optimised a way
Performance Caching and Traffic Scaling
The crux of the problem is that the data isn’t stored efficiently. If you want to store things in a way that you can query them quickly to find posts, you have to use taxonomies. That’s what taxonomies are built for, else categories and tags would be stored in post meta
Meta queries are extremely slow
Don’t expect more than a handful of people to be able to view that page concurrently before things start falling over and page load times skyrocket. Meta queries are super expensive
Maybe you can cache them though?
You can never cache that page
Because it shows different things to different users, if you started caching the page it would show the same thing to all users.
Data Storage
If session is a post ID, you should use the post parent instead to link them.
Otherwise, you would be better off hooking into post save, and checking if the session is the highest number and storing it in user meta, so that next time you need it, you’ve already figured it out and it’s a simple/fast get_user_meta call