I noticed that the syntax is different, when using scisql_s2PtInBox and qserv_areaSpec_Box. Could it be the issue? scisql_s2PtInBox(ra,decl,0.4,0.9,0.6,1.1)=1 qserv_areaSpec_box(0.4,0.9,0.6,1.1) sql> select * from DeepForcedSource where scisql_s2PtInBox(ra,decl,0.4,0.9,0.6,1.1)=1 LIMIT 3000 [2015-02-11 07:34:10] 1,000 row(s) retrieved starting from 0 in 33441/38157 ms sql> select * from DeepForcedSource where qserv_areaSpec_box(0.4,0.9,0.6,1.1) LIMIT 3000 [2015-02-11 07:36:48] [42S02][1051] Unknown table 'result_4492663601' [2015-02-11 07:36:48] [Proxy][4120] Error during execution: -1 Ref=1 Resource(/chk/LSST/7140): 20150211-07:36:36, Error merging result, 1470, [1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'QST_1_.,0.4,0.9,0.6,1.1)=1 LIMIT 3 (-1) On Feb 11, 2015, at 7:18 AM, Tatiana Goldina <[log in to unmask]> wrote: > I don't understand. Both ra,decl and x,y columns are present in DeepForcedSource table, and I am able to run a non-optimized version of the query, using scisql_s2PtInBox(ra, decl, lon1, lat1, lon2, lat2). Why I can not use the optimized version - qserv_areaSpec_box? > > Tatiana > > On Feb 10, 2015, at 11:40 PM, Kian-Tat Lim <[log in to unmask]> wrote: > >> Folks, >> >>> Here's what's happening: >>> 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. >> >> I agree; 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. >> >> ForcedSources don't contain ra/decl (or even x,y), so specifying >> a box for them is inappropriate. >> >> -- >> 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 >> >> >> -- >> BEGIN-ANTISPAM-VOTING-LINKS >> ------------------------------------------------------ >> >> Teach CanIt if this mail (ID 04NOTIDkW) is spam: >> Spam: https://canit.ipac.caltech.edu/canit/b.php?i=04NOTIDkW&m=83fc2b258401&c=s >> Not spam: https://canit.ipac.caltech.edu/canit/b.php?i=04NOTIDkW&m=83fc2b258401&c=n >> Forget vote: https://canit.ipac.caltech.edu/canit/b.php?i=04NOTIDkW&m=83fc2b258401&c=f >> ------------------------------------------------------ >> END-ANTISPAM-VOTING-LINKS > ######################################################################## 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