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