Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel Seq Scan
Date
Msg-id CAA4eK1KCymW+-vJuAgSxf-s4K-0X3dBxDcw5Hem+qSgergxY4A@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Mon, Oct 12, 2015 at 11:51 AM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
>
> On Mon, Oct 5, 2015 at 11:20 PM, Amit Kapila <amit.kapila16@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
Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Postgres service stops when I kill client backend on Windows
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH v1] GSSAPI encryption support