Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Here's an update of the patch. I reverted the behavior at end of scan > back to the way it was in Jeff's original patch, and disabled reporting > the position when moving backwards.
Applied with minor editorializations --- notably, I got rid of the HeapScanDesc dependency in syncscan.c's API, so that it could be used in other contexts (VACUUM, anyone?). There were a few glitches in the heapam.c code too. > I didn't touch the large scan threshold of NBuffers / 4 Tom that > committed as part of the buffer ring patch. IOW I removed the GUC > variable from the patch. I think the jury is still out there on this one. Yeah, this could do with more testing. I concur with the idea that the threshold should be the same for both bits of code, though. Otherwise we have four behaviors to try to tune, instead of two. > I included a basic regression test as well. I did not commit this, as it seemed a bit useless --- it's looking for a minor side-effect and not doing much of anything to prove that the code does what's intended. Possibly we could put in a real test after Greg's concurrent-psql thing is in. Jeff wrote: > I might go so far as to suggest if the scan *ever* moves backwards, we > taint the scan such that it never reports. This would be a trivial addition to the code-as-committed (clear rs_syncscan upon backing up by a page) but I didn't add it. Any strong feelings one way or the other? AFAIK the only case where it'd happen is if someone reads forwards in a large-seqscan cursor for awhile and then reads backwards. You could argue that doing that is a good reason to drop them out of the syncscan pack ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend