On Mon, Oct 12, 2015 at 11:51 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > > On Mon, Oct 5, 2015 at 11:20 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > For now, I have fixed this by not preserving the startblock incase of rescan > > for parallel scan. Note that, I have created a separate patch > > (parallel_seqscan_heaprescan_v1.patch) for support of rescan (for parallel > > scan). > > while testing parallel seqscan, My colleague Jing Wang has found a problem in > parallel_seqscan_heapscan_v2.patch. >
Thanks for spotting the issue. > In function initscan, the allow_sync flag is set to false as the > number of pages in the > table are less than NBuffers/4. > > if (!RelationUsesLocalBuffers(scan->rs_rd) && > scan->rs_nblocks > NBuffers / 4) > > As allow_sync flag is false, the function > heap_parallelscan_initialize_startblock is not > called in initscan function to initialize the > parallel_scan->phs_cblock parameter. Because > of this reason while getting the next page in > heap_parallelscan_nextpage, it returns > InvalidBlockNumber, thus it ends the scan without returning the results. > Right, it should initialize parallel scan properly even for non-synchronized scans. Fixed the issue in attached patch. Rebased heap rescan is attached as well. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
parallel_seqscan_heapscan_v3.patch
Description: Binary data
parallel_seqscan_heaprescan_v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
