On Mon, Oct 5, 2015 at 8:20 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> [ new patch for heapam.c changes ]
I went over this in a fair amount of detail and reworked it somewhat.
The result is attached as parallel-heapscan-revised.patch. I think
the way I did this is a bit cleaner than what you had, although it's
basically the same thing. There are fewer changes to initscan, and we
don't need one function to initialize the starting block that must be
called in each worker and then another one to get the next block, and
generally the changes are a bit more localized. I also went over the
comments and, I think, improved them. I tweaked the logic for
reporting the starting scan position as the last position report; I
think the way you had it the last report would be for one block
earlier. I'm pretty happy with this version and hope to commit it
soon.
There's a second patch attached here as well, parallel-relaunch.patch,
which makes it possible to relaunch workers with the same parallel
context. Currently, after you WaitForParallelWorkersToFinish(), you
must proceed without fail to DestroyParallelContext(). With this
rather simple patch, you have the option to instead go back and again
LaunchParallelWorkers(), which is nice because it avoids the overhead
of setting up a new DSM and filling it with all of your transaction
state a second time. I'd like to commit this as well, and I think we
should revise execParallel.c to use it.
Finally, I've attached some test code in parallel-dummy.patch. This
demonstrates how the code in 0001 and 0002 can be used. It scans a
relation, counts the tuples, and then gratuitously rescans it and
counts the tuples again. This shows that rescanning works and that
the syncscan position gets left in the right place.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company