Tom Lane kirjutas N, 09.01.2003 kell 04:05: > I said: > > Yeah, backwards scan is not implemented for quite a large number of plan > > node types :-(. I am not sure that it is practical to fix them all. > > I have been toying with the notion of making cursors on complex plans > > safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan,
How much work would it be do the MATERIAL node so that it is calculated at the time of initial forward scan (i.e. FETCH/MOVE) ? > if the top plan node isn't one that can handle backwards scan. > > I forgot to mention plan B: make use of ReScan. This could work like > so: > > 1. Cursor keeps track of row number (number of rows it's fetched). > > 2. To scan backwards when top plan type doesn't handle it, rewind all > the way with ReScan, then move forward the appropriate number of rows. > > This would avoid any added overhead in the case where a backwards move > is never requested, and it also would support MOVE BACKWARD ALL quite > efficiently (much more so than now). On the other hand, it'd really > suck if the user asks for backwards scan from a point far into the > output. > > Perhaps we could do something with a hybrid technique: don't materialize > the cursor output unless user actually asks for backwards scan. If he > does, then create a tuplestore and put the data into it (rescanning the > query output to do so), and finally supply the tuples from the tuplestore. How hard would it be to save "snapshots" of scan state at certain places, say at each 1000 tuples, so that a full re-scan is not neccessary ? > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Hannu Krosing <[EMAIL PROTECTED]> ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
