SharePoint
Feedback by UserVoice

Pramod Nathan

My feedback

  1. 1,046 votes
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)

      We’ll send you updates on this idea

      138 comments  ·  Sites and Collaboration » Document Libraries  ·  Flag idea as inappropriate…  ·  Admin →

      We are continuing to make our large list experiences better, please keep the feedback coming.

      Spring 2018 update:
      - We now support being able to manually add indexes to lists of any size (increased from lists up to 20,000 items previously).
      - Starting with the February release of the Office 365 Excel client, you will be able to export your full list instead of getting cut off part of the way through.

      What we are working on now:
      - Predictive indexing will start to work for lists larger than 20,000 items so your views will automatically cause the right indexes to be added to your lists.

      In our backlog:
      - Being able to index/sort/filter by lookup column types (like person, lookup or managed metadata columns) without being throttled.
      - Making sure that our REST APIs support querying in ways that will guarantee that the call will not be throttled.

      For…

      Pramod Nathan supported this idea  · 
      Pramod Nathan commented  · 

      Remove List view threshold limit of 5000 by taking advantage of paging

      The current list view threshold limit of 5000 with it's workarounds are very frustrating. We can all appreciate that we do not want to fetch too many items from the table (the underlying cause of the restriction). BUT paging exists and Microsoft needs to take better advantage of this:

      1. The SharePoint interface is page based. Instead of breaking (which is what the solution does with a warning), MS can change the underlying call so it breaks down the call to SQL to fetch data as needed per page/set of pages. When the user navigates to the next page/set of pages - call SQL for the next set of data (e.g. if I am on the current view with 5000+items, I really don't care about about item 5000+1 immediately. BUT I do care that I can manipulate the entire set of items and that I can get to item 5001). So just fetch the first few page worth of items.

      2. For sorting and filtering, the call can go to SQL on click to fetch the top X number of items depending on the filter or sort. (e.g. if the page has 5000+items and we want to sort by a column, it can call a SQL statement that does this but sends back only the top 3-4 pages or how many ever are feasible)

      3. It will also make the underlying APIs very robust in terms of being able to create multiple calls of data to generate a large data sets that are stored in SharePoint lists and libraries.

    Feedback and Knowledge Base