On a more important level, though, you might rethink how you are approaching the task. You may have 80,000 records, but obviously you don't need all of them at once (or maybe ever)...and if even if a manager "insists" that they need all of them, there's no way they can meaningfully interpret 80,000 records.
Because of that, it might be better to start your grid's store with a few default filters, just to keep the initial record count to a reasonable level. Telling the user that there are 80,000 records to page through is not helpful, but telling them that they have 2 pages of 25 records each is. So if there are ways to start the grid off in an already-filtered manner, you might have more success
And of course, you can always add or change filters via an input form. The point is, though, that for usability purposes, don't think about your data set in terms of the whole...think of it in terms of what is important to the people who will be using the app. Chances are, such considerations will give your opportunities to filter that total recordset by 90% right off the bat.
Sorting has to be implemented serverside (typically the server has far better hardware and will do a far quicker job of sorting large data sets).
Once the server has sorted the data it can tell the grid to reload its data store which will fetch the first page of sorted data.
To do this client-side with the number of records you dealing with would not be feasible.
(i.e Trying to drag down 80 000 data store records would take forever).
We can dynamically sort 50 000 items and reload the grid data store in under 10 seconds.