Re: idea for concurrent seqscans

Jeff Davis <jdavis-pgsql(at)empires(dot)org> writes:
> (1) Do we care about reverse scans being done with synchronized
> scanning? If so, is there a good way to know in advance whether it is
> going to be a forward or reverse scan (i.e. before heap_getnext())?

There are no reverse heapscans --- the only case where you'll see
direction = backwards is while backing up a cursor with FETCH BACKWARD.
I don't think you need to optimize that case.

What I'm more concerned about is your use of shared memory. I didn't
have time to look at the patch, but how are you determining an upper
bound on the amount of memory you need? What sort of locking and
contention issues will there be?

Another point is that this will render the results from heapscans
unstable, since different executions of the same query might start
at different points. This would for example probably break many
of the regression tests. We can deal with that if we have to, but
it raises the bar of how much benefit I'd want to see from the patch.

One detail that might or might not be significant: different scans are
very likely to have slightly different ideas about where the end of the
table is, since they determine this with an lseek(SEEK_END) at the
instant they start the scan. I don't think this invalidates your idea
but you need to watch out for corner-case bugs in the coding.

regards, tom lane