Comment 29 for bug 1712854

Bill,

For reference, here's the performance I'm seeing on a set of ~60k holds, where each record has between 200 and 2k holds. The hold shelf has 126 holds on it (I can only click "Don't Print" so many times...). This is all on an under-powered, everything-including-the-db-on-one-vm 2-vcpu test server:

 * 126 holds (on the shelf) load in 1.5 seconds, click to render
 * 200 holds load in under 3 seconds
 * 2k holds load in about 15 seconds

I don't think we're giving up much there, TBH. But have you tested with your data set? It'll be larger in aggregate, and per record/shelf I'm sure. If it's significantly slower than what I'm seeing, I'd be very interested in seeing an explain-analyze of the new core hold listing query!

Setting my numbers on initial load speed aside, though, and particularly for the hold shelf where queue position is really not important -- it's on the shelf, their position is "it's ready, come get it" -- I can see removing the queue position column and directly paging there. The drawbacks are that we can't sort on calculated columns, and printing the hold shelf is /precisely/ a pain point for actual users, even at small libraries, and this puts printing at a significant disadvantage. That said, it's still going to be enormously faster to print, even if we do have to re-fetch the data.

I don't think users are ready to give up queue position on the Record -> View Holds UI, though, do you? That's the one interface where it is sorta related to the context (holds for this record) and might be useful as a sort column.

For the pull list, where the primary use case is actually printing and queue position isn't important (it's de facto "1"), front-loading the data to make sorting and printing the whole set very fast seems ideal, so I'd argue for the way the API is used now be how we make use of it in the pull list.

Thanks!