K-T,
> I don't understand this. I thought the entire point was to use
> the individual subchunk tables for things like near neighbor, not the
> merged table, which would be used for all other types of queries. In
> that mode, the performance doesn't look too bad:
Yes, indeed, but I and Daniel thought we'd check "just in case",
hoping that perhaps merge engine is smarter than we think it is,
which would simplify our design a little.
> The open files may or may not be a problem; having tens of
> thousands open is usually not an issue.
That can be easily tested.
We will keep the merge engine as an option. I like its simplicity...
Jacek
########################################################################
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
|