We cannot guarantee that secondary index implementations (particularly
the one used by googlesource.com) can efficiently paginate based on
the sortkey, and in particular can both sort and reverse sort on the
same field. This particular performance issue notwithstanding,
searching is now generally fast enough that it is feasible just to
skip the first N results when doing pagination.
Add an option S= to QueryChanges to support starting at a nonzero
offset. Note that we still have to fetch n+S results from the index in
order to do visibility filtering, since if we skipped at the index
layer we wouldn't know how many of the skipped elements would have
matched later filtering.
Drop the sortkey token suffix from the legacy anchor parser; there is
no reliable way to convert it to an offset, and it's unlikely that
users have permalinks to specific sortkey values.
On the server side, remove the sortkey field from the current index
version, and use pagination by offset instead of sortkey in the new
version only.
Continue to support sortkey queries against old index versions, to
support online reindexing while clients have an older JS version.
Change-Id: I6a82965db02c4d534e2107ca6ec91217085124d6
86caf9ec23