Re: Cursors: getting the number of tuples; moving backwards - Mailing list pgsql-general

From am@fx.ro
Subject Re: Cursors: getting the number of tuples; moving backwards
Date
Msg-id 20021102213342.A292@coto
Whole thread Raw
In response to Re: Cursors: getting the number of tuples; moving backwards  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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)

pgsql-general by date:

Previous
From: Hubert depesz Lubaczewski
Date:
Subject: Re: problems with building recent cvs snaphots
Next
From: miguel angel rojas aquino
Date:
Subject: OT : timestamps and jbuilder (help, please)