What does TOP mean ?

[Douglas Tody]

Looking at this another way, one could argue that TOP in TAP (ADQL) and
TOP in SSA are actually very similar.

In ADQL/SQL, TOP is normally used in connection with an ordering of the
response table that is explicitly controlled by the client, e.g. using
ORDER BY or some such mechanism.  This is the nature of ADQL/SQL, where
the query statement explicitly specifies what is to be computed.

In SSA, TOP is doing the same thing, but the ordering is computed
automatically by the service.  If we were to add a function SCORE to
ADQL equivalent to what the SSA scoring heuristic does, then TOP with
ORDER BY SCORE would provide functionality in TAP equivalent to what SSA
TOP provides (I am not really suggesting we do this, merely pointing out
the relationship).  Likewise, one could add additional parameters to
PQL to further control the semantics of TOP.

MAXREC is something completely different, controlling only the output
processing of the service, with the query language controlling the
logical content of the table produced.  If these services were to
support a paging mechanism, that would be closely related to what MAXREC
is currently doing, and again independent of the query language.  Much
of the confusion for TAP I think, concerns TOP vs MAXREC.

 	- Doug


On Tue, 28 Apr 2015, Marco Molinaro wrote:

> Hi all,
> leaving out the scoring topic related to TOP in SSAP, I wouldn't consider
> the ADQL.TOP something to compare to to the TOP in SSAP.
> Dave neatly pointed out the TAP perspective for the MAXREC + TOP layering,
> that comes from two different interfaces, MAXREC for TAP, TOP inside ADQL.
> In SSAP I think the user expects the same behavior, but the query part is
> directly internal to the SSAP "parametric query language".
> If (when?) a general PQL for IVOA comes up (again) we can discuss whether
> for simple protocols it is better to change TOP into BEST (or whatever) not
> to create confusion to users, or whether the PQL should keep as much as
> possible the reserved words coming from the SQL experience of ADQL&TAP.
>
> Cheers,
>    Marco
>
> ps - BTW, TOP was brought up also in Banff (IIRC) inside the pagination of
> results...maybe this is something to keep in mind when there will be a need
> to reuse/redefine it
>
> 2015-04-28 1:56 GMT+02:00 Douglas Tody <dtody at nrao.edu>:
>
>> Yes; basically, TOP is another query parameter, whereas MAXREC controls
>> the output processing, for any type of service and any query language.
>>
>>
>>
>> On Tue, 28 Apr 2015, Dave Morris wrote:
>>
>>
>>> On 2015-04-27 16:03, Markus Demleitner wrote:
>>>
>>>>
>>>> And regarding Walter's interjection:
>>>>
>>>>  I thought that the difference between MAXREC and TOP is that MAXREC
>>>>> requires an overflow indicator, while TOP would prohibit it.
>>>>>
>>>>
>>>> Interesting thought -- is it intended to work this way? [it doesn't
>>>> in DaCHS, and a quick search in the 1.1 specs didn't give me anything
>>>> pointing in that direction]
>>>>
>>>>
>>> For a TAP service.
>>>
>>> I don't know what the specifications say, but as an end user, I would
>>> expect that the server returns the lesser of the two, TOP or MAXREC.
>>>
>>> However, if MAXREC caused the truncation, then that would be an overflow,
>>> if TOP cause the truncation, then it would not.
>>>
>>> If TOP > MAXREC, then return MAXREC rows and flag an overflow. Which
>>> means this probably would hit MAXREC and return an overflow :
>>>
>>>    SELECT TOP 1000000000000000000 * FROM table
>>>
>>> If TOP < MAXREC, then return TOP rows and no overflow. So I would not
>>> expect to get an overflow for this :
>>>
>>>    SELECT TOP 1 * FROM table
>>>
>>> I would probably expect the other services to behave in a similar manner.
>>>
>>> Hope this helps,
>>> Dave
>>>
>>> --------
>>> Dave Morris
>>> Software Developer
>>> Wide Field Astronomy Unit
>>> Institute for Astronomy
>>> University of Edinburgh
>>> --------
>>>
>>>
>