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
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 |