Fix Version/s: None
(by Daniel) qserv_areaspec_box asks qserv to choose chunk/row coverage according to the director table. Generally, it detects the director table from the query, computes the region against the index, and then substitutes the right directive. But in this case, there is no director table, only a child table. Hence, even if we know what the director table is, its columns are not available to use in the query, unless we rewrite to add an equi-join with the director table. The best we can do in this case (without adding a join), is to use the parameters for determining chunk coverage, and then covering all rows in those chunks. The user could specify additional conditions to apply spatial filtering based on other (non-partitioning) columns.
Another thing we could do is to detect scisql region directives in the WHERE clause, but this expands the detection and dependence on scisql name/syntax (the first is in the angle distance condition when determining spatial join evaluability).
Anyway, what I'm trying to say is that the right thing to do isn't completely clear, and the possible options are not that simple to implement (though the ones I've listed are certainly possible, and should be much easier than refmatch support).
- relates to
DM-1985 Reject queries involving qserv_areaSpec_box on non-partitioned tables
There was a confusion, if table has ra/dec, then we should support it, even if it is slow. After talking to K-T, we agreed to reopen it.
I believe this ticket is still relevant?
I view it as a requirement at the ADQL level: whether we support geometry queries or not against tables in Qserv should not, to first order, depend on whether the tables are partitioned or not.
But perhaps this ticket is not the right place to carry out any further debate?
qserv_area_spec is deprecated. The proposed/supported alternative, direct use of scisql_s2PtIn*, already works correctly for well-formulated queries on any sort of table.
I agree with Daniel's initial sentiment as expressed in
DM-1985: if qserv_areaspec_box is specified to work only against Object (or other director table) ra/decl columns, then using it in a query where those columns are unavailable should be rejected. I think auto-including the director table with a join is more magic than is needed.
Basically, ForcedSources don't contain ra/decl (or even x,y), so specifying a box for them is inappropriate.
I would close this as Won't Fix.