Q: Complex Magma Indexed queries - draft syntax

[Chris Muller]

> Comments welcome

This is sounding good so far, I am encouraged.  You
have zoomed straight to where, for me, the core
(not-easily-solved) challenge is..

> Server Side Request Work
> ------------------------------
> Here is where I am still very vague, but the idea is
> that just as with the existing queries, each clause
> will be able to
> find the oids between the minimum and maximum
> hashes.
> 
> I have no idea on performance, but could each clause
> not modify a bitmap index appropraitely ?

Absolutely, and I assume we can find a good implement
to efficiently represent the intersection (Bitmap,
BitArray, RunArray, LargePositiveInteger, whatever..).

But we still have to figure out how to *calculate*
that Bitmap, BitArray, RunArray or
LargePositiveInteger from the MaHashIndexes given the
Clause-tree as input.  As it stands, I see no way to
avoid enumerating the entire range for each condition,
which could take a long time..

If we can figure out this part of the puzzle, I think
the rest may be just implementation details..

> Paging
> --------
> Subsequent requests from the client for pages of
> objects, will submit the bitmap with the request.

Ok, this is much faster than actually creating the
(temporary) intersected MaHashIndex, but will require
some close scrutiny of the paging code to work with
the Bitmap.