Re: scrollable cursor support without MOVE statement

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com>
Cc: <pgsql-patches(at)postgresql(dot)org>,<magnus(at)hagander(dot)net>,<bruce(at)momjian(dot)us>
Subject: Re: scrollable cursor support without MOVE statement
Date: 2007-04-16 21:01:14
Message-ID: 1176757274.3635.364.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-patches

On Wed, 2007-03-28 at 17:42 +0200, Pavel Stehule wrote:
> >
> >This is the most recent email I have on this. Was the scrollable patch
> >applied? If not, would you resubmit?
> >
>
> I resubmit scrollable cursor patch

I notice your patch has been accepted, though admit I hadn't noticed it
previously.

Can I ask a question relating to the patch?
How is the scrollability determined?

Scrollable cursors and sorts don't mix very well in terms of
performance, as you may know. Previously, since NOSCROLL was the only
option, this wasn't a problem. Now that we have scrollable cursors, it
is an issue, since according to the doc change the scrollability default
is neither scroll nor noscroll.

I'm concerned that many PL/pgSQL routines will now run slower because
they may now be considered scrollable when they previously were not. How
is the scrollability determined? Do we look at the kids of FETCH being
used to determine whether we need scrolling? (which would be great) Or
will we have to manually change all existing PL/pgSQL code so that it is
definitely NOSCROLL? (which would be unacceptable). Or?

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Steve 2007-04-16 22:13:54 Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)
Previous Message Zoltan Boszormenyi 2007-04-16 20:54:45 Re: Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch