Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id DE0FD475EC9 for ; Thu, 20 Jun 2002 08:23:11 -0400 (EDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by postgresql.org (Postfix) with SMTP id CAF1B475BB5 for ; Thu, 20 Jun 2002 08:23:10 -0400 (EDT) Received: from psc.progress.com (HELO Yahoo.com) (janwieck@192.233.92.200 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Jun 2002 12:23:11 -0000 Message-ID: <3D11C92E.F05D0E80@Yahoo.com> Date: Thu, 20 Jun 2002 08:23:10 -0400 From: Jan Wieck X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.14-6.1.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Momjian Cc: Wei Weng , pgsql-sql@postgresql.org Subject: Re: Which one is faster? References: <200206192034.g5JKYn616099@candle.pha.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Archive-Number: 200206/270 X-Sequence-Number: 8235 Bruce Momjian wrote: > > Wei Weng wrote: > > Between Using Limit P, S or using a cursor to start from FETCH ABSOLUTE > > S and FETCH NEXT for P times, which one is faster? > > LIMIT is faster because it doesn't need to generate all the result, in > some cases. Neither does using a cursor need to generate all the results first. It's a portal, which is an executor state on hold, and FETCH is implemented as ExecutorRun() with the number of wanted result rows as limitation. Since LIMIT generates internally one more result row than really wanted, I don't think LIMIT would be much faster, but it's for sure less portable. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #