Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 844EA9FA304 for ; Mon, 11 Dec 2006 05:39:30 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 45878-08-2 for ; Mon, 11 Dec 2006 05:39:25 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mx1.ipf.is (mack.ipf.is [85.197.192.164]) by postgresql.org (Postfix) with ESMTP id 358BB9FA2E0 for ; Mon, 11 Dec 2006 05:39:24 -0400 (AST) Received: (qmail 11736 invoked by uid 1010); 11 Dec 2006 09:36:12 +0000 Received: from 88.149.106.19 by mack (envelope-from , uid 1008) with qmail-scanner-1.25-st-qms (clamdscan: 0.88.4/1639. spamassassin: 3.1.4. perlscan: 1.25-st-qms. Clear:RC:1(88.149.106.19):SA:0(-2.4/4.5):. Processed in 0.451636 secs); 11 Dec 2006 09:36:12 -0000 X-Antivirus-HIVE-Mail-From: gnari@hive.is via mack X-Antivirus-HIVE: 1.25-st-qms (Clear:RC:1(88.149.106.19):SA:0(-2.4/4.5):. Processed in 0.451636 secs Process 11729) Received: from dsl-149-106-19.hive.is (HELO ?192.168.1.33?) (88.149.106.19) by mx1.ipf.is with SMTP; 11 Dec 2006 09:36:11 +0000 Subject: Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can From: Ragnar To: Chris Cc: Mark Kirkwood , pgsql-performance@postgresql.org In-Reply-To: <457CF427.30507@gmail.com> References: <457814D3.1030001@mbsi.com.br> <457CD182.7020004@gmail.com> <1165809878.19970.2.camel@localhost.localdomain> <457CE03C.1060707@gmail.com> <457CF184.6020702@paradise.net.nz> <457CF427.30507@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 11 Dec 2006 09:39:32 +0000 Message-Id: <1165829972.6369.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/213 X-Sequence-Number: 22269 On mán, 2006-12-11 at 17:01 +1100, Chris wrote: > Mark Kirkwood wrote: > > Chris wrote: > > > >> It's the same as doing a select count(*) type query using the same > >> clauses, but all in one query instead of two. > >> > >> It doesn't return any extra rows on top of the limit query so it's > >> better than using pg_numrows which runs the whole query and returns it > >> to php (in this example). > >> > >> > >> Their docs explain it: > >> > >> http://dev.mysql.com/doc/refman/4.1/en/information-functions.html > >> > >> See "FOUND_ROWS()" > >> > > > > Note that from the same page: > > > > "If you are using SELECT SQL_CALC_FOUND_ROWS, MySQL must calculate how > > many rows are in the full result set. However, this is faster than > > running the query again without LIMIT, because the result set need not > > be sent to the client." yes but not any faster than a select count(*) from (full query without LIMIT) so the only advantage to the SQL_CALC_FOUND_ROWS thingie is that instead of doing select count(*) from full-query select * from query-with-LIMIT which will do the query twice, but possibly with different optimisations, you would do a non-standard select SQL_CALC_FOUND_ROWS query-with-LIMIT select FOUND_ROWS() which will do one full query, without any LIMIT optimisation, but with the same number of round-trips, and same amount of data over the line. the only case where the second way may be more effective, is if no LIMIT optimisation can be made, and where the dataset is larger than file buffer space, so that there is no effect from caching. gnari