pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Josh Berkus <josh@agliodbs.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
To: pgsql-sql@postgreSQL.org
Subject: Re: [SQL] Cursors and backwards scans and SCROLL
Date: Sun, 9 Mar 2003 12:59:35 -0800
Message-ID: <200303091259.35423.josh@agliodbs.com> (raw)
In-Reply-To: <21621.1047242111@sss.pgh.pa.us>
References: <21621.1047242111@sss.pgh.pa.us>

Tom,

> Postgres' implementation of cursors has always had a problem with doing
> MOVE or FETCH backwards on complex queries. 

Coincidnetally enough, I was just chatting with one of my contractors 
yesterday about how the one thing that Transact-SQL has to offer is a really 
good cursor implementation.   It would be lovely to improve ours to match.

> Fixing this directly seems unreasonably difficult, so I'm currently
> working on fixing it by inserting a Materialize plan node at the top of
> the plan tree for a cursor, if the plan tree couldn't otherwise support
> backwards scan.  The Materialize node will save aside a copy of each row
> as it's fetched from the underlying plan, and use this copied table if
> any backwards scanning is asked for.

Sounds good to me.  It's also very similar to what T-SQL does for a STATIC or 
KEYSET cursor, and works very well in their implementation.  (FWIW, T-SQL's 
cursor types, such as DYNAMIC and KEYSET, are unnecessary for Postgres due to 
MVCC)

> 2. Error out only if a backwards fetch is actually attempted on a plan
> tree that can't handle it (which could only happen if SCROLL wasn't
<snip>
> I'm presently leaning to #2, even though it exposes implementation
> details.  I'm open to discussion though.  Any preferences?  Other ideas?

This sounds like a good idea to me in a staggered-implementation sense if it's 
doable.  That is, we'd implement the behavior in #2 in the next version of 
Postgresql, and the behavior in #1 or in #3 in the version after that.    If, 
however, the implementation of #2 is too difficult, then I think #3 would be 
a good choice.



view thread (15+ messages)  latest in thread

Message-ID: <200303091259.35423.josh@agliodbs.com>
Permalink:  ../200303091259.35423.josh@agliodbs.com/
Also on:    postgresql.org/message-id/200303091259.35423.josh@agliodbs.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: josh@agliodbs.com, tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
  Subject: Re: [SQL] Cursors and backwards scans and SCROLL
  In-Reply-To: <200303091259.35423.josh@agliodbs.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox