Date: Mon, 11 Dec 2006 07:42:14 +0100
From: Andreas Kostyrka <andreas@kostyrka.org>
To: Chris <dmagick@gmail.com>
Cc: Mark Kirkwood <markir@paradise.net.nz>,
	pgsql-performance@postgresql.org
Subject: Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can
Message-ID: <20061211064214.GV2050@andi-lap.la.revver.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <457CF427.30507@gmail.com>
User-Agent: mutt-ng/devel-r804 (Debian)

* Chris <dmagick@gmail.com> [061211 07:01]:
> select SQL_CALC_FOUND_ROWS userid, username, password from users limit 10;
> 
> will do:
> 
> select userid, username, password from users limit 10;
> 
> and calculate this:
> 
> select userid, username, password from users;
> 
> and tell you how many rows that will return (so you can call 'found_rows()').
> 
> 
> the second one does do a lot more because it has to send the results across to the client program - whether the client uses that info or not doesn't matter.
Not really. Sending the data to the client is usually (if you are not
connected via some small-bandwidth connection) a trivial cost compared
to calculating the number of rows.

(Our tables involve 100Ms of rows, while the net connectivity is a
private internal Gigabit net, returning the data seems never to be an
issue. Reading it from the disc, selecting the rows are issues. Not
sending the data.)

Actually, if you think that sending the data is an issue, PG offers
the more generic concept of cursors.

Andreas