Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: Parallel Seq Scan
Date
Msg-id CAJrrPGcAMmgYj80606B404LeHJ4CQi6NQnvK8YJT4ib3Y2T5yg@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers


On Thu, Oct 15, 2015 at 6:32 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Wed, Oct 14, 2015 at 3:29 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think this got messed up while rebasing on top of Gather node
> changes, but nonetheless, I have changed it such that PartialSeqScan
> node handling is after SeqScan.

Currently, the explain analyze of parallel seq scan plan is not showing the allocated number of workers
including the planned workers.I feel this information is good for users in understanding the performance
difference that is coming with parallel seq scan. It may be missed in recent patch series. It was discussed
in[1].

Currently there is no qualification evaluation at Result and Gather nodes, because of this reason, if any
query that contains any parallel restricted functions is not chosen for parallel scan. Because of 
this reason, there is no difference between parallel restricted and parallel unsafe functions currently.
Is it fine for first version? 

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH v3] GSSAPI encryption support
Next
From: Craig Ringer
Date:
Subject: Re: PATCH: 9.5 replication origins fix for logical decoding