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?
e.g.
# explain (analyse, buffers, timing, verbose, costs) select count(*)
from js where content->'tags'->>'title' like '%de%'; QUERY
PLAN
--------------------------------------------------------------------------------------------------------------------------------------Aggregate
(cost=105557.59..105557.60 rows=1 width=0) (actual
time=400.752..400.752 rows=1 loops=1) Output: count(*) Buffers: shared hit=175333 -> Gather
(cost=1000.00..104931.04rows=250621 width=0) (actual
time=400.748..400.748 rows=0 loops=1) Output: content Number of Workers: 2 Buffers: shared
hit=175333 -> Parallel Seq Scan on public.js (cost=0.00..39434.47
rows=125310 width=0) (actual time=182.256..398.14 rows=0 loops=1) Output: content Filter:
(((js.content-> 'tags'::text) ->>
'title'::text) ~~ '%de%'::text) Rows Removed by Filter: 626486 Buffers: shared hit=87666
-> Parallel Seq Scan on public.js (cost=0.00..39434.47
rows=1253101 width=0) (actual time=214.11..325.31 rows=0 loops=1) Output: content Filter:
(((js.content-> 'tags'::text) ->>
'title'::text) ~~ '%de%'::text) Rows Removed by Filter: 6264867 Buffers: shared
hit=876667Planningtime: 0.085 msExecution time: 414.713 ms
(14 rows)
And perhaps associated PIDs?
Thom