Re: number of rown in a cursor.

From: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
To: Christoffer Gurell <orbit(at)0x63(dot)nu>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: number of rown in a cursor.
Date: 2005-01-24 17:14:14
Message-ID: 1106586853.16640.97.camel@state.g2switchworks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 2005-01-24 at 10:58, Christoffer Gurell wrote:
> > Not without actually scanning the result, if that's what you meant.
>
> so basically i have to do a move to the end ?

yep. This is because one of the advantages of a cursor is that it only
runs partially and returns the first X rows for the fetch. This keeps
load down so that many cursors hitting the machine at once don't all
materialize all their rows and chew up all that I/O, cpu, and memory.
Unfortunately, one of the side effects of this methodology is that no
one knows how many rows there really are until they've been fetched.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Klugmann 2005-01-24 17:23:28 Re: Problem getting sql statement logging to work
Previous Message Christoffer Gurell 2005-01-24 16:58:41 Re: number of rown in a cursor.