Re: [SQL] does LIMIT save time?

>
>
> Hi,
>
> is using SELECT LIMIT faster than using SELECT without LIMIT on
> the same query? If yes, in what way? What is if I use ORDER in the
> SELECT clause?

    First  of  all,  LIMIT reduces the amount of data sent to the
    client application.  Thus  it  reduces  network  traffic  (or
    interprocess communication if run on the same system), and it
    saves wasted memory in the client to buffer received  results
    that aren't wanted.

    For  the  backend processing time it depends on the execution
    plan generated by the optimizer if  much  or  less.   If  the
    query  plan tells the executor that the result must be sorted
    or grouped,  then  the  entire  result  set  must  first  get
    collected and sorted before the correct portion of the result
    set could be returned. Such a sort or group step is caused by
    the  ORDER  or  GROUP  clauses.  The  optimizer  has  limited
    capability to realize if the index he has choosen for a  scan
    will  already  present  the data in the wanted order and then
    suppress the sorting.

    So in general, LIMIT itself could never hurt.  ORDER can  but
    someone  who  cares  for  speed  is normally willing to setup
    appropriate multi key indices to prevent sort steps.

>
> Is it possible to get the *total* number of rows selected (ie. doing
> the query virtually without LIMIT) when using a LIMIT clause?

    Absolutely not. In  the  optimal  case  (no  sort  step)  the
    executor  aborts  the  table scans when reaching the limit. A
    well placed LIMIT can dramatically reduce disk IO.  Now  look
    at  the  main road and count the red cars passing by over the
    day. After 10 minutes you stop - do you know  how  many  cars
    will have passed at midnight? The executor is exactly in that
    situation - he stop's scanning so he can't know.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #