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