Yes it does. So the reason for the COUNT stage is that COUNT will terminate when all the input records have been exhausted regardless of whats going on between FANINTWO and LOOKUP. Nice ... -- bc
On Thu, Aug 6, 2009 at 3:41 PM, Melinda W. Varian<[email protected]> wrote: > On Thu, 2009-08-06 at 15:01 -0400, Bob Cronin wrote: >> Just for my own edification, could you explain in a bit more detail >> why Lookup doesn't terminate when the records I am NOT feeding back to >> it via the fanintwo (i.e. what would constitute the sole source of >> records on the primary input were the fanintwo not there) runs out? I >> mean, if there's no more records there, there's no chance anything >> else will arrive on the secondary input of the fanintwo ... > > Bob, here in essence is your pipeline: > . . . | > f: fanintwo | > l: lookup | > . . . > > l: | f: > > "fanintwo" doesn't terminate until either its output stream > goes to end-of-file (i.e., "lookup" terminates) or BOTH of its > input streams go to end-of-file. > > Its first input stream will go to end-of-file when all of the > input records have been processed. But its secondary input > stream won't terminate until "lookup" terminates. > > "lookup" won't terminate until it sees end-of-file on its > input (or until all of its outputs go to end-of-file, which > doesn't happen here). > > Thus, "lookup" is waiting for "fanintwo" to terminate, and > "fanintwo" is waiting for "lookup" to terminate. There is > no way for either of them to know that there are no more > records. As long as they still have an input stream > connected, which both of them do, they have to continue > running in case any more records show up. > > This is a classic stall. > > Does that help? > > Melinda >
