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