 |
 |
Yes, but DeepForcedSource is a child table, so its rows are not partitioned (or indexed) according to its own ra/decl rows. The presence of ra and decl in DeepForcedSource rows that correspond to their linked row in the director table (DeepSource?) are currently only leveraged during partitioning. The presence of the director table's ra/decl is not assumed to exist in child tables, because for ForcedSource, we can't afford to have them. Thus query execution doesn't leverage it. There isn't a provision to use our spatial indexing when a table has columns with values that (only) might be sort-of-close to the values used for partitioning (and indexing). You can workaround this by joining with the director table. This is kind of a design decision for us: the only spatial indexing you get is when a director table is involved--we didn't really expect to optimize spatial searches without the director table. But there are things we could do to make this a bit nicer--detecting the scisql_ptInBox (?) syntax would at least allow similar syntax for the user for director/child table querying. -Daniel On 02/11/2015 08:41 AM, Kian-Tat Lim wrote: > Tatiana, > >> I don't understand. Both ra,decl and x,y columns are present in DeepForcedSource table, > My mistake, and my apologies. I was looking at the ForcedSource > table in the baseline schema. If we do have ra, decl in the table, then > perhaps we should be able to use qserv_areaspec_box on those columns. > ######################################################################## 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