Details
-
Type:
Story
-
Status: Invalid
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Qserv
-
Labels:None
-
Story Points:20
-
Epic Link:
-
Team:Data Access and Database
Description
(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).
Attachments
Issue Links
- relates to
-
DM-1985 Reject queries involving qserv_areaSpec_box on non-partitioned tables
- Invalid
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.