Re: execute cursor fetch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: my ho <mthoatbanjo(at)yahoo(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: execute cursor fetch
Date: 2004-10-12 14:07:56
Message-ID: 1856.1097590076@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

my ho <mthoatbanjo(at)yahoo(dot)com> writes:
> If anyone can help pls, I have a question abt the
> execution of cursor create/fetch/move , in particular
> about disk cost. When a cursor is created, is the
> whole table (with the required columns) got put into
> memory?

No. The plan is set up and then incrementally executed each time you
say FETCH.

> how does postgre speed up the query in
> compare to normal selection?

The only difference from a SELECT is that the planner will prefer
"fast-start" plans, on the theory that you may not be intending
to retrieve the whole result. For instance it might prefer an
indexscan to a seqscan + sort, when it otherwise wouldn't.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Gabriele Bartolini 2004-10-12 14:29:36 Re: Normal case or bad query plan?
Previous Message Stef 2004-10-12 13:05:15 Re: execute cursor fetch