c# - Entity Framework Pagination Performance Considerations -

i'm unfamiliar complex queries in entity framework 6, had question associated pagination.

the scenario follows: have project have described data model in own form , using t4 templates, generates appropriate entity, high fidelity change tracking companion entity, complex dynamic search query entity used ask questions associated model (eg. entity.searchnamecriterium = "t"; entity.searchnametype = stringsearchtype.startswith, ui built around enable user powerful search tool.)

into this, have part pagination used drop down list of constituent elements: when insert using insert button, if overflows next page (at 'x' number of items each time, defined in constant -- later move setting) use following code:

this.context.savechanges(); int offset = searchcuritemlstcriteriaskip - 1; var querybase = this.querycuritemlstformcontainer; int idfind = newdatacontext.identifier; while (querybase.any()) {     querybase = querycuritemlstformcontainer.skip((++offset) * searchcriteriacount).take(searchcriteriacount);     if (querybase.any(k => k.identifier == idfind))     {         this.searchcuritemlstcriteriaskip = offset * searchcriteriacount;         break;     } } 

the rationale item entered @ point within db on current page or after current page, can in theory start @ current page , move forward.

i want know if there's better way this, or if methodology works...? in case wonders: combobox used select current item because list waste space, ever need 1 item @ time, , search functionality works in combobox's dropdown. ui elements associated generated xaml through text templates.

i want sure understand kind of impact query on moving newest page have on large databases.

what performance considerations of doing query.select(k=>k.identifier).count() / itemsperpage? quicker in instance?

insight more welcome.

based on focus of this, using count() on query, , limiting selection identifier: few orders of magnitude faster use count functionality.

rationale behind is: if you're paging , use iterative approach, if there 10,000 records, , 25 items per page, that's @ least 800 queries (400 checking if there's more items, 400 checking identifier range) hit database, whereas count one.

even though count can seen potentially costly operation, latency between of queries database in stated method greater single count request. simplest solution best.