Heikki Linnakangas <heikki@enterprisedb.com> 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
