Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel Seq Scan
Date
Msg-id CAA4eK1LAfy27+jTqHe-vwqW7Qn96UBUVuXMC+Ca67UwUazNBRA@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Antonin Houska <ah@cybertec.at>)
Responses Re: Parallel Seq Scan  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
On Wed, Jul 15, 2015 at 2:14 PM, Antonin Houska <ah@cybertec.at> wrote:
>
> Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Attached, find the rebased version of patch.
>
> [I haven't read this thread so far, sorry for possibly redundant comment.]
>
> I noticed that false is passed for required_outer agrument of
> create_partialseqscan_path(), while NULL seems to be cleaner in terms of C
> language.
>
> But in terms of semantics, I'm not sure this is correct anyway. Why does
> create_parallelscan_paths() not accept the actual rel->lateral_relids, just
> like create_seqscan_path() does? (See set_plain_rel_pathlist().) If there's
> reason for your approach, I think it's worth a comment.
>

Right, I think this is left over from initial version where parallel seq scan
was supported just for single table scan.  It should probably do similar to
create_seqscan_path() and then pass the same down to
create_partialseqscan_path() and get_baserel_parampathinfo().

Thanks, I will fix this in next version of patch.



With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] postgres_fdw extension support
Next
From: Amit Kapila
Date:
Subject: Re: assessing parallel-safety