Re: LIMIT Optimization
От | alexandre paes :: aldeia digital |
---|---|
Тема | Re: LIMIT Optimization |
Дата | |
Msg-id | 00c401c1a5ce$986841e0$fc01a8c0@aldeiadigital.com.br обсуждение исходный текст |
Ответ на | Re: LIMIT Optimization (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-sql |
Hi, Syntax of the "optimization" in other plataforms: DB2 : [Optimization For n Rows] ( [Fetch-First n ] = PostgreSQL's LIMIT ) Oracle: [/*fastfirstrows*/] SQL Server: [FastFirstRows] - version 6.x // [FAST(n)] - version >= 2000 I simulate the "optmization" in PostgreSQL using: 1. SELECT * FROM <table> WHERE <cond> ORDER BY <order> LIMIT 10 (Explain this query show a Index Scan) 2. Loop in resultset. If the <cond> is break in <= 10 rows continue, else 3. Repeat the query without LIMIT The times of queries in DB2 and PostgreSQL are same doing it. ------------ Alexandre ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Bruce Momjian" <pgman@candle.pha.pa.us> Cc: "alexandre paes :: aldeia digital" <alepaes@aldeiadigital.com.br>; <pgsql-sql@postgresql.org> Sent: Friday, January 25, 2002 3:58 PM Subject: Re: [SQL] LIMIT Optimization > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > So, it is only valuable for cursors > > Right; I can see no rhyme or reason for attaching it to a plain SELECT, > unless the system provides some way of stopping short of fetching all of > a SELECT, which we don't. A CURSOR would be the analogous thing in PG. > > regards, tom lane
В списке pgsql-sql по дате отправления: