How can I fetch just some include properties from my query and still update it if changes are made?

I have this query

var payout = await _dbContext.StripePayouts
    .Include(p => p.StripeAccount)
    .Include(p => p.User)
    .Where(p => p.Id == payoutId)
    .FirstAsync();

and I only need 2 properties from 'User' and just 1 property from StripeAccount, so I don't want to fetch the whole entity as they are both large. But I also need to save properties from StripePayouts, so I can't use a select on it.

QUESTION - Is there a way I can write this query so that I only fetch what I need instead of all properties from all of the included entities, but still be able to save changes to StripePayout?

Ex. I only need a single property from StripeAccount named "AccountId" and with User I only need a property called "Email".

Something like this?

.Include(p => p.User.Select(q => new {
    Name = q.UserName,
    Email = q.UserEmail
})

I know I can do this below, but I have to be able to save some of those properties from StripePayout (ex. HasFetchedTransfers) if they need to be changed. No values from the child entities (StripeAccount, User) have to be changed.

var payout = await _dbContext.StripePayouts
    .Select(p => new 
    {
        Id = p.Id,
        FailureResubmitStatus = p.FailureResubmitStatus,
        HasFetchedTransfers = p.HasFetchedTransfers,
        StripePayoutId = p.StripePayoutId,
        // no changes to these values below 
        StripeAccountId = p.StripeAccount.AccountId,
        UserEmail = p.User.Email,
        UserName = p.User.UserName,
    })
    .FirstOrDefaultAsync(p => p.Id == payoutId);

My general advice when it comes to EF and applications is to avoid treating Entities as a data transport where they travel between separate actions. (reads and writes)

In a web application for instance use a View Model defined and projected just like your example at the end to selectively pull the information from the aggregate structure that you need. Then if/when you go to persist changes to that entity, reload just the entity or entities you need to update. You don't need to re-load the entire aggregate root to do so. The same applies to thick client applications. We don't need an entire aggregate structure to display information to a user and there is still a lag time between when the information was first read, and when that user chooses to submit any changes.

An added consideration for this is detecting and handling concurrent updates. For example if there is something like a RowVersion or Timestamp on the record that can be compared during the update to warn about changes that have been recorded between the time that the data snapshot was taken and the update is made. Detecting details like this requires going back to get the current persisted state at the time of update, and this shouldn't be anything frowned upon as unnecessary or expensive. Reading a single record from the database by PK for instance is about as fast an operation as you're going to get, and it is the only way to ensure you aren't potentially dealing with stale state. If there is a possibility that another user/instance could have read and updated that row between those two points in time, the application should handle that possibility.