Re: Parallel Seq Scan
От | Robert Haas |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | CA+TgmoaUz3f-rujFpzB4EyQ8FgC2sdDAZpY=fpBvCXMk6y2-KQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Tue, Apr 21, 2015 at 9:38 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Mon, Apr 20, 2015 at 10:08 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> >> On Tue, Apr 7, 2015 at 11:58 PM, Amit Kapila <amit.kapila16@gmail.com> >> wrote: >> > One disadvantage of retaining parallel-paths could be that it can >> > increase the number of combinations planner might need to evaluate >> > during planning (in particular during join path evaluation) unless we >> > do some special handling to avoid evaluation of such combinations. >> >> Yes, that's true. But the overhead might not be very much. In the >> common case, many baserels and joinrels will have no parallel paths >> because the non-parallel paths is known to be better anyway. Also, if >> parallelism does seem to be winning, we're probably planning a query >> that involves accessing a fair amount of data, > > Am I understanding right that by above you mean to say that retain the > parallel and non-parallel path only if parallel-path wins over non-parallel > path? Yes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: