On Tue, Jan 27, 2015 at 3:18 AM, Jim Nasby <jim.na...@bluetreble.com> wrote: > > On 1/23/15 10:16 PM, Amit Kapila wrote: >> >> Further, if we want to just get the benefit of parallel I/O, then >> I think we can get that by parallelising partition scan where different >> table partitions reside on different disk partitions, however that is >> a matter of separate patch. > > > I don't think we even have to go that far. > > > We'd be a lot less sensitive to IO latency. > > I wonder what kind of gains we would see if every SeqScan in a query spawned a worker just to read tuples and shove them in a queue (or shove a pointer to a buffer in the queue). >
Here IIUC, you want to say that just get the read done by one parallel worker and then all expression calculation (evaluation of qualification and target list) in the main backend, it seems to me that by doing it that way, the benefit of parallelisation will be lost due to tuple communication overhead (may be the overhead is less if we just pass a pointer to buffer but that will have another kind of problems like holding buffer pins for a longer period of time). I could see the advantage of testing on lines as suggested by Tom Lane, but that seems to be not directly related to what we want to achieve by this patch (parallel seq scan) or if you think otherwise then let me know? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
