 |
 |
Daniel, > The join code thinks that there are always benefits to subchunk a > subchunked table when it is being joined. It is stupid, but at least > it provides correct results under some circumstances. I added a TODO > to think about this, because it doesn't seem like something that we > can design and define in our heads as we write code. You might > consider the join predicate (hello, USING() and ON() syntax) and > what columns are indexed (hello, metadata) or approximate sizes of > chunk and subchunk tables. Sometimes it looks like query analyzer > and optimizer problem. It looks easy to get wrong. I don't think we should be trying to outsmart MySQL (or the DBA) here. I believe the only queries for which subchunking is definitively better are spatially-limited self-joins, which hopefully are relatively easy to recognize. All other queries should just be passed through as is (at least until subchunking is proven to help them). -- 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