Tom,thanks for your good summary.
Seems this is the latest posting for this thread.
> -----Original Message-----
> From: Tom Lane
>
> Philip Warner <pjw@rhyme.com.au> writes:
> > Do you really think it's not such a good idea to have different
> optimizer
> > behaviour for SELECT and DECLARE CURSOR? My expectation is that
> putting a
> > SELECT statement inside a cursor should not change it's
> performance. I'd be
> > interested to know the reasons for your choice.
>
> I think it's an excellent idea to have different behaviors, and the
> reason is that we know a stand-alone SELECT will deliver all its result
> rows, whereas for DECLARE it's quite possible that not all the possible
> result rows will be fetched. Moreover, the user is likely to fetch the
> cursor's results in bite-size chunks, so he will be interested in
> average response time as well as total time.
>
Cursors have a different character from stand-alone SELECT.
We don't have to FETCH results continuously from cursors.
It's well known that an average response time is significant
in some applications. For example,we could make interactive
paging applications which require a next/prior page(small part
of the result of a query) according to user's request.
There may be more excellent ways to achive it but I don't
know how to do it in PostgreSQL.
Regards.
Hiroshi Inoue