<div dir="ltr">Hi Mark, hi all,<div>I second your proposal and Markus comment on arguments</div><div>order.</div><div><br></div><div>I may agree with François-Xavier, but would you use</div><div>CONTAINS or DISTANCE in that case?</div><div><br></div><div>I also agree that Laszlo&#39;s input is too much for ADQL-2.1,</div><div>especially at this stage. I suggest Laszlo to join the DAL list</div><div>and keep us alerted.</div><div><br></div><div>Cheers</div><div>    Marco</div><div><br></div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">2017-11-05 11:40 GMT+01:00 Mark Taylor <span dir="ltr">&lt;<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Laszlo,<br>
<br>
thank you for this input.  It might be a promising direction for<br>
future major revisions of ADQL, but since I&#39;m no kind of database<br>
expert, I&#39;m not qualified to say.<br>
<br>
However, it&#39;s addressing a somewhat different problem than I&#39;ve<br>
raised in this thread, which is proposing one of the several<br>
existing equivalent options within the existing ADQL 2.1 syntax<br>
to use as a preferred form for a common type of crossmatch.<br>
Your suggestion would be a significant new addition to the ADQL<br>
syntax which I doubt (? unless the authors disagree) is<br>
appropriate for a minor ADQL update, especially near the end of the<br>
revision process.<br>
<br>
I&#39;ll leave it to others to consider whether this looks like<br>
something worth pursuing for ADQL v3.<br>
<br>
Best wishes,<br>
<br>
Mark<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, 4 Nov 2017, Dobos, Laszlo wrote:<br>
<br>
&gt; Hi guys,<br>
&gt;<br>
&gt; I&#39;m not on the DAL list but Tamas Budavari forwarded the mail to me so let<br>
&gt; me chip in. In the new skyquery, we put the cross-match definition into the<br>
&gt; FROM clause but not as a list of joined tables but rather something like a<br>
&gt; table-valued function. Putting it into the FROM clause is much better than<br>
&gt; in the WHERE clause, not because it&#39;s much easier to parse but because if<br>
&gt; it&#39;s in the WHERE clause, it&#39;s quite hard to sort the other conditions out<br>
&gt; if there&#39;s complex boolean algebra allowed in the clause. If xmatching has<br>
&gt; some special, custom syntax, then the possibility of writing queries that<br>
&gt; cannot be executed can be minimized. Also, putting it into the xmatch clause<br>
&gt; makes query rewriting much easier because you simply replace the xmatch part<br>
&gt; with the output of the xmatch operation and leave all other joins in place<br>
&gt; to execute the final query.<br>
&gt;<br>
&gt; Here&#39;s an example:<br>
&gt;<br>
&gt; SELECT s.objid, s.ra, s.dec, g.objid, g.ra, g.dec, x.ra, x.dec<br>
&gt; INTO twowayxmatch<br>
&gt; FROM XMATCH<br>
&gt;      (MUST EXIST IN SDSSDR7:PhotoObjAll AS s WITH(POINT(s.ra, s.dec),<br>
&gt; ERROR(0.1, 0.1, 0.1)),<br>
&gt;       MUST EXIST IN GALEXGR6:PhotoObjAll AS g WITH(POINT(g.ra, g.dec),<br>
&gt; ERROR(0.2, 0.2, 0.2)),<br>
&gt;       LIMIT BAYESFACTOR TO 1e3) AS x<br>
&gt; WHERE s.ra BETWEEN 0 AND 5 AND s.dec BETWEEN 0 AND 5<br>
&gt;     AND g.ra BETWEEN 0 AND 5 AND g.dec BETWEEN 0 AND 5<br>
&gt;<br>
&gt; The MUST EXIST will soon be extended to MAY EXIST and MUST NOT EXIST<br>
&gt; (drop-outs, but for those, you need the footprints). This syntax is quite<br>
&gt; extensible, because you can add more catalog-specific options to the WITH()<br>
&gt; part. For instance, we could support extended source matching by replacing<br>
&gt; POINT with ELLIPSE, etc. LIMIT BAYESFACTOR could be replaced with LIMIT<br>
&gt; SEPARATION etc. to use a different algorithm.<br>
&gt;<br>
&gt; We also support region-based filtering with the REGION clause. This is<br>
&gt; intentionally not on defined on a per-table basis to avoid query plan<br>
&gt; complexities.<br>
&gt;<br>
&gt; SELECT s.objid, s.ra, s.dec, g.objid, g.ra, g.dec, x.ra, x.dec<br>
&gt; INTO twowayxmatch<br>
&gt; FROM XMATCH<br>
&gt;      (MUST EXIST IN SDSSDR7:PhotoObjAll AS s WITH(POINT(s.ra, s.dec),<br>
&gt; ERROR(0.1, 0.1, 0.1)),<br>
&gt;       MUST EXIST IN GALEXGR6:PhotoObjAll AS g WITH(POINT(g.ra, g.dec),<br>
&gt; ERROR(0.2, 0.2, 0.2)),<br>
&gt;       LIMIT BAYESFACTOR TO 1e3) AS x<br>
&gt; REGION &#39;CIRCLE J2000 0 0 5&#39;<br>
&gt;<br>
&gt; You can try it here: <a href="http://test.voservices.net/skyquery" rel="noreferrer" target="_blank">http://test.voservices.net/<wbr>skyquery</a> . It doesn&#39;t<br>
&gt; support adql yet but I&#39;m working on that.<br>
&gt;<br>
&gt; -Laszlo<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:dal-bounces@ivoa.net">dal-bounces@ivoa.net</a> [mailto:<a href="mailto:dal-bounces@ivoa.net">dal-bounces@ivoa.net</a>] On Behalf Of Mark<br>
&gt; Taylor<br>
&gt; Sent: Friday, November 3, 2017 5:27 PM<br>
&gt; To: Francois-Xavier PINEAU &lt;<a href="mailto:francois-xavier.pineau@astro.unistra.fr">francois-xavier.pineau@astro.<wbr>unistra.fr</a>&gt;<br>
&gt; Cc: <a href="mailto:dal@ivoa.net">dal@ivoa.net</a><br>
&gt; Subject: Re: ADQL 2.1: Preferred crossmatch syntax<br>
&gt;<br>
&gt;<br>
&gt; On Fri, 3 Nov 2017, Francois-Xavier PINEAU wrote:<br>
&gt;<br>
&gt; &gt; Dear Mark and DAL,<br>
&gt; &gt;<br>
&gt; &gt; Although I agree with the approach, there is one point that bothers me.<br>
&gt; &gt;<br>
&gt; &gt; I know that not everyone agrees on the matter, but I personally prefer<br>
&gt; &gt; to declare the cross-match condition in the JOIN (like in your<br>
&gt; &gt; InteropOct2015DAL<br>
&gt; &gt; presentation) rather than in the WHERE.<br>
&gt; &gt;<br>
&gt; &gt; In fact, in relational algebra, I prefer to see the cross-match as a<br>
&gt; &gt; theta-join, not as a selection on the result of a cross-product.<br>
&gt;<br>
&gt; OK, I don&#39;t really have an opinion on that, I never really know about what<br>
&gt; syntax is best for joins, or whether it makes a difference.<br>
&gt; [And I&#39;m afraid I wouldn&#39;t know a theta-join if one trod on my foot]<br>
&gt;<br>
&gt; Is it likely to make a difference in performance terms which of these two<br>
&gt; ways it&#39;s done?  I.e. do we need to specify here what&#39;s the preferred way to<br>
&gt; use a constraint like DISTANCE()&lt;threshold, or is this something we can<br>
&gt; harmlessly leave to the taste of the query author?<br>
&gt;<br>
&gt; Mark<br>
&gt;<br>
&gt; --<br>
&gt; Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK<br>
&gt; <a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a>  <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~<wbr>mbt/</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
--<br>
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a>  <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~<wbr>mbt/</a></div></div></blockquote></div><br></div></div></div>