 |
 |
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