Re: Cursors: getting the number of tuples; moving backwards

am@fx.ro

From: am@fx.ro
To: pgsql-general@postgresql.org
Cc: Martijn van Oosterhout <kleptog@svana.org>, am@fx.ro, pgsql-general@postgresql.org
Date: 2002-11-02T19:33:43Z
Lists: pgsql-hackers, pgsql-general
On Fri, Nov 01, 2002 at 10:03:17PM -0500, Tom Lane wrote:
> MOVE does execute the query, it just doesn't ship the tuples to the
> client.  This would save some formatting overhead (no need to run
> the datatype I/O conversion procedures), but unless you have a slow
> network link between client and server I would not expect it to be
> "much" faster ...

It must be the fact that the computer is quite old : Cyrix 6x86 166Mhz.
( this is not the deplyoment machine ).

Using MOVE is about 5 times faster in my case :
For 150784 tuples in the table, FETCH-ing took about 1m30 ,
while MOVE-ing took only about 17sec. 

                           |  Real       |  User        |  Sys
-------------------------------------------------------------------
select * from PRODTEST     |  1m30.843s  |  0m42.960s   |  0m1.720s
-------------------------------------------------------------------
declare cursor... + FETCH  |  1m32.835s  |  0m42.680s   |  0m1.780s
-------------------------------------------------------------------
declare cursor... + MOVE   |  0m17.215s  |  0m0.030s    |  0m0.030s
-------------------------------------------------------------------
( i used commands like:   time psql -f test.sql db_rex 
  to get those timings )


The difference must be smaller on fast machines.

So i guess that my computer is pretty good when it comes to finding
performance problems in applications   ;-)


Bye,
Adrian Maier
(am@fx.ro)