Re: Parallel Seq Scan
От | Thom Brown |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | CAA-aLv6OWR3GO35YEpEVULcmpYFYU52LPd5q1qs5i0CJ0xefag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Parallel Seq Scan
Re: Parallel Seq Scan |
Список | pgsql-hackers |
On 13 November 2015 at 15:22, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Fri, Nov 13, 2015 at 7:59 PM, Thom Brown <thom@linux.com> wrote: >> >> On 13 November 2015 at 13:38, Amit Kapila <amit.kapila16@gmail.com> wrote: >> > On Wed, Nov 11, 2015 at 11:40 PM, Pavel Stehule >> > <pavel.stehule@gmail.com> >> > wrote: >> >> >> >> >> >> yes - the another little bit unclean in EXPLAIN is number of workers. >> >> If I >> >> understand to the behave, the query is processed by two processes if >> >> workers >> >> in the explain is one. >> >> >> > >> > You are right and I think that is current working model of Gather >> > node which seems okay. I think the more serious thing here >> > is that there is possibility that Explain Analyze can show the >> > number of workers as more than actual workers working for Gather >> > node. We have already discussed that Explain Analyze should >> > the actual number of workers used in query execution, patch for >> > the same is still pending. >> >> This may have already been discussed before, but in a verbose output, >> would it be possible to see the nodes for each worker? >> > > There will be hardly any difference in nodes for each worker and it could > be very long plan for large number of workers. What kind of additional > information you want which can't be shown in current format. For explain plans, not that useful, but it's useful to see how long each worker took for explain analyse. And I imagine as more functionality is added to scan partitions and foreign scans, it will perhaps be more useful when the plans won't be identical. (or would they?) >> >> And perhaps associated PIDs? >> > > Yeah, that can be useful, if others also feel like it is important, I can > look into preparing a patch for the same. Thanks. Thom
В списке pgsql-hackers по дате отправления: