From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "alexandre paes :: aldeia digital" <alepaes(at)aldeiadigital(dot)com(dot)br> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: LIMIT Optimization |
Date: | 2002-01-25 17:32:53 |
Message-ID: | 200201251732.g0PHWrd27513@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
alexandre paes :: aldeia digital wrote:
> Hi,
>
> DB2, Sql Server and Oracle have a smart optimization sql-clause (DB2
> example):
>
> SELECT * FROM <table> WHERE <cond> ORDER BY <order> OPTMIZATION FOR n ROWS
>
> The [OPTMIZATION FOR] clause turns the query fast by optimize the first "n"
> rows.
> If the query returns more than "n" rows, the query is slowest if compared
> with a normal
> query, but it does not have the limitation of PostgreSQL's LIMIT clause.
>
> I think that clause performs the search twice: one for optimize and other if
> the # of rows
> is great then "n".
>
> It's possible to include this in future releases of PostgreSQL ????
So it forces our LIMIT optimization, without limiting the number of rows
returned. That seems to be of questionable value. The only value I can
see for it is for CURSOR queries but I don't think we can start
returning rows from even a cursor until the entire query is done
executing.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-01-25 17:52:11 | Re: LIMIT Optimization |
Previous Message | Arve Fahlvik | 2002-01-25 16:29:53 | Complex column ref. |