Daniel,
> The general case is very expensive (lookup position and chunk for each
> position!?), and we are only going to get away with it because our
> bulk-loads for ForcedSource will be spatially-restricted.
I'm pretty sure that ForcedSource and (final) Object tables will
be available at the same time, so the partitioner could look up the
coordinates based on objectId using a simple merge. I thought you were
already going to have a central objectId-to-chunk (or even subchunk?)
index anyway; scanning an input ForcedSource table for all its objectIds
and then doing a single query (or at least batching objectIds to reduce
the number of queries by an order of magnitude) to get the mappings
doesn't sound ridiculous.
--
Kian-Tat Lim, LSST Data Management, [log in to unmask]
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1
|