Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Mark Kirkwood" <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, <pgsql-bugs(at)postgresql(dot)org>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7
Date: 2009-06-09 18:00:43
Message-ID: 4A2E5CFB020000250002777E@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote: 
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> This seems like the only option that will produce correct answers,
>> so it gets my vote.  How much is the performance penalty for
>> materializing the tuplestore?  I'm inclined to think that whatever
>> it is, you just have to pay it if you ask for a WITH HOLD cursor.
> 
> I don't mind paying it for a WITH HOLD cursor, since by definition
> you're asking for a more expensive behavior there.  The thing that
> is bothering me more is whether we want to pay a price for a *non*
> WITH HOLD cursor.  You can get instability for seqscan or volatile
> functions if you just try MOVE BACKWARD ALL and re-read.
 
I would expect to pay more for a scrollable cursor than non-
scrollable; and in fact, the fine manual says "Depending upon the
complexity of the query's execution plan, specifying SCROLL might
impose a performance penalty on the query's execution time."  That
would tend to argue in favor of taking the time to produce correct
answers.  It does raise a question, though, about another sentence in
the same paragraph: "The default is to allow scrolling in some cases;
this is not the same as specifying SCROLL."  Either we make people pay
for this when they haven't specified SCROLL but PostgreSQL has
historically given it to them anyway, or we might break existing
applications.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-06-09 18:09:11
Subject: Re: information_schema.columns changes needed for OLEDB
Previous:From: Robert HaasDate: 2009-06-09 18:00:41
Subject: Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7

pgsql-bugs by date

Next:From: Jaime CasanovaDate: 2009-06-09 18:15:56
Subject: Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7
Previous:From: Robert HaasDate: 2009-06-09 18:00:41
Subject: Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group