Open Stack

On 21 November 2014 04:38, Michael Krotscheck <krotscheck at gmail.com> wrote:
> Hey there, Jay-
>
...
> I would characterize your use case as an individual contributor who prefers
> to treat their task list like a queue. This is one valid use case, and
> marker based paging solves your problem. However, the other use cases above
> think of stories more like a spreadsheet, and they require an indicator of
> where they are relative to the rest of entire set. From a practical
> perspective, most usage would never go past the second page, so I am not
> really concerned about the performance implications of simply passing offset
> straight through to the SQL query, and I would hope that storyboard's
> filtering capabilities are powerful enough that our users can reduce the
> size of the result set to a manageable size. However, we ALSO get all that
> with offset based paging, and we win the the ability to support all the
> other use cases without sacrificing anything.
>
> In short, using offset based paging requires a small investment of time,
> costs a performance hit for a small subset of users, and allows us to meet
> the needs of all of our use cases.

I note above that you say 'most usage will never go past the second
page'. For interactive users in the web UI thats likely true (but for
real data, consider reaching out to e.g. launchpad and asking them
about usage patterns).

However for API usage, complete scans of result sets are much more
common, and they caused substantial remedial performance work to be
needed in Launchpad (which was also built with the idea that only the
first few pages need to be fast).

If I may be so bold, the rule of thumb 'if we can't do it fast, don't
do it' is a very sensible one for many API implementations, and one
that I rather suspect will apply here.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud