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

Reply via email to