Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can

From: Andreas Kostyrka <andreas(at)kostyrka(dot)org>
To: Chris <dmagick(at)gmail(dot)com>
Cc: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, pgsql-performance(at)postgresql(dot)org
Subject: Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can
Date: 2006-12-11 06:42:14
Message-ID: 20061211064214.GV2050@andi-lap.la.revver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

* Chris <dmagick(at)gmail(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ravindran G - TLS, Chennai. 2006-12-11 07:37:54 Postgresql - Threshold value.
Previous Message Chris 2006-12-11 06:01:11 Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can