Hi Jacek -
Proposing to consider the following approach: - pick one index and rely on it. Most likely this would be spatial index (even most temporal queries use ra,decl...) - sort the data based on that index (make it a clustered index) - keep the whole index in memory Based on current db size estimate, we would need for ra,decl index (worst case): - 117 GB for DR1 - 250 GB for DR2 - 420 GB for DR20 which is very reasonable. - rely on that index as much as possible: force its use first in every query that has spatial constraints.
If we were going to stick with one index, I would recommend adding the temporal component to it. This will be especially helpful for designing queries looking for moving objects, which are at a different RA, DEC at any given moment. The temporal component of LSST is arguably one of its biggest assets, and I would think the database should be designed to reflect this.
I'm not sure what the additional overhead is for adding a third element to the index. If its just a factor of 1.5, this would not make the "very reasonable" in any way "unreasonable".
Cheers, Andy _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
