Re: [PATCHES] scrollable cursor support without MOVE statement

2007-04-18 Thread Simon Riggs
On Mon, 2007-04-16 at 18:56 -0400, Tom Lane wrote:
> the default behavior is still the same

Just had time to check this. You're right, my mistake.

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



---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [PATCHES] scrollable cursor support without MOVE statement

2007-04-17 Thread Pavel Stehule



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.


I resubmited this patch because Bruce removed it from queue instead of GUC 
protection patch




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.


default is 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?



default is without changes on functionality.

Regards
Pavel Stehule

_
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. 
http://messenger.msn.cz/



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [PATCHES] scrollable cursor support without MOVE statement

2007-04-16 Thread Tom Lane
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Mon, 2007-04-16 at 18:18 -0400, Tom Lane wrote:
>> There is no change in the default behavior.

> Previously:
> - PL/pgSQL cursors were non-scrollable
> - DECLARE CURSOR cursors were not non-scrollable by default

No, they weren't "non-scrollable", they were the same as the default
case for DECLARE CURSOR.  You just couldn't tell (from within plpgsql
anyway) for lack of any form of FETCH that would exercise backward
motion.

The actual code behavior is, and has been for a long time,

SCROLL -> if plan doesn't handle backwards scan, stick a Materialize
node atop it so it can.

NO SCROLL -> do nothing to plan.  In pquery.c, throw error if an attempt
is made to fetch backwards.

default -> if plan doesn't handle backwards scan, use NO SCROLL behavior.
If it does, silently allow scrolling.

The previous state of affairs was that plpgsql had no way to specify
SCROLL or NO SCROLL and so always got the default behavior.  Now it
does, but the default behavior is still the same.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [PATCHES] scrollable cursor support without MOVE statement

2007-04-16 Thread Simon Riggs
On Mon, 2007-04-16 at 18:18 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > I'm concerned that many PL/pgSQL routines will now run slower because
> > they may now be considered scrollable when they previously were not.
> 
> There is no change in the default behavior.

Previously:
- PL/pgSQL cursors were non-scrollable
- DECLARE CURSOR cursors were not non-scrollable by default

The new docs say it is "query dependent", whereas previously the default
was non-scrollable. That sounds like a change in the default behaviour,
so I'm trying to dig a little deeper.

Are you saying that if I don't say anything at all then a cursor will be
non-scrollable? 

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



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [PATCHES] scrollable cursor support without MOVE statement

2007-04-16 Thread Tom Lane
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I'm concerned that many PL/pgSQL routines will now run slower because
> they may now be considered scrollable when they previously were not.

There is no change in the default behavior.

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [PATCHES] scrollable cursor support without MOVE statement

2007-04-16 Thread Simon Riggs
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



---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PATCHES] scrollable cursor support without MOVE statement

2007-03-28 Thread Bruce Momjian

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---


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
> 
> Regards
> Pavel Stehule
> 
> _
> Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. 
> http://messenger.msn.cz/

[ Attachment, skipping... ]

> 
> ---(end of broadcast)---
> TIP 6: explain analyze is your friend

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings