Hi Andy
The overhead related to adding 3rd element to the index is reasonable,
the only problem with such composite index is that you have to use a
constraint on the very first column of a composite index, so in practice
a query without spatial constraint will not be able to use such index.
BTW, the cleanest solution to providing truly good support for both
spatial and temporal queries is to duplicate data and optimize (cluster)
each copy differently (and I know Jim Gray agrees with that 100%).
The only problem is the cost (however this might turn out to be
the cheapest solution anyway...)
Jacek
Andrew Becker wrote:
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
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
