Re: Parallel Seq Scan
| От | Amit Kapila |
|---|---|
| Тема | Re: Parallel Seq Scan |
| Дата | |
| Msg-id | CAA4eK1LAfy27+jTqHe-vwqW7Qn96UBUVuXMC+Ca67UwUazNBRA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Parallel Seq Scan (Antonin Houska <ah@cybertec.at>) |
| Ответы |
Re: Parallel Seq Scan
|
| Список | 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.
>
>
> 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.
В списке pgsql-hackers по дате отправления: