| From: | Christoffer Gurell <orbit(at)0x63(dot)nu> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: number of rown in a cursor. |
| Date: | 2005-01-24 18:38:16 |
| Message-ID: | 20050124183816.GA29580@h55p111.delphi.afb.lu.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> 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.
the thing is that i want to create a gui-widget that has the possibility
to show a large amount of data over a slow connection. My idea was that
i create a cursor and create a srollbar with the number of rows in the
cursor so the user can scroll and only fetch the rows displayed from the
cursor as the user releases the scrollbar.
If i understand right then the way to do this is: create the cursor,
move to the end to get the number of rows, move to the front. get data.
am i right? or is there a better way to achieve this ? perhaps with a
local view?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-01-24 18:40:19 | Re: on update / on delete performance of foreign keys |
| Previous Message | Jeff Davis | 2005-01-24 18:27:08 | Re: disable trigger from transaction |